Erik McClure

We Aren't Designing Software For Robots

"I have the solution, but it only works in the case of a spherical cow in a vacuum." - *[old physics proverb](*
Whenever I am designing something, be it an API or a user interface, I try to remember that I am not designing this for a perfectly rational agent. Instead, I am designing software for a bunch of highly emotional, irrational creatures called *human beings*, all of whom have enormously different tastes. I try to include options, or customization, or if that isn't possible, a compromise. I try to keep the door open, to let my software be used as a tool to enhance someone's productivity no matter what workflow they use, instead of trying to impose my own workflow on them.

For some reason, many programmers seem to struggle with the concept of people being different. They get hung up on this naïve concept of right or wrong, as if life is some kind of mathematical equation that has a closed form solution. Let me say right now that any solution to life is going to be one heck of a chaotic nonlinear PDE, which won’t have any closed form solution at all, and certainly not one using elementary functions. When you are developing software, you must keep in mind the range of customers who will be using your product, whether they are office workers or fellow programmers.

Maybe someone is using your product to try and finish a presentation in time to go home and catch a nap before they get up to work their second job so they can support a wife and a screaming baby. Someone else might use your product to track their progress as they try to revolutionize search from their bedroom instead of study for their finals next week. Someone else might be an elderly man trying to figure out how his vacation is going to go.

We are all different. We arise from all walks of life and are bound together in a great journey on this blue ball hurtling through space. It is not cowardice when two people try to put aside their differences and work together, it is strength. It requires enormous courage to admit that there are no simple answers in life. There are no answers in the back of the textbook. There are many different answers, all different in subtle ways, all suitable for slightly different circumstances, all both right and wrong in their own, strange, quirky ways.

Some programmers seem distressingly incapable of compassion or empathy. Many claim to live through the cold hard logic of data, without apparently realizing that data itself is inherently meaningless. It is only given meaning through a human’s interpretation, and a human can interpret data to mean whatever they want. They seem to think they can solve problems by reducing everyone into neat little collections of numbers that can be easily analyzed. It’s certainly a lot less frustrating to work with real numbers instead of real people, but inevitably, a programmer must come to terms with the fact that life is about human beings, not numbers on a screen.

The cold hard logic of our code is good for speaking to computers—it is not good for speaking to other human beings.



I wonder how your design compares to YAGNI?

Two customers could have differing opinions on multiple features of a program. With M customers and N features you might want to prune their options drastically to what can be tested and maintained - is this the restriction you see as trying to impose one's own workflow?

Tan Tan

Hi! So I got to thinking about this article, and thought of sharing a way I think it relates to me.
I've been working on a game mod that, up until recently, was playing itself for the most part. It didn't account for the user at all, it just went about a perfect set of instructions and provided no challenge, depth, or hardly any time in the experience with all the events zooming by. I had to, in a way, dumb it down to wait for the player to progress or provide choices which I as a designer had to get creative with. The most meaningful or logical point of view I have can be biased by my view as the creator, and I have to remove myself from that perspective in order to improve the product. Or get some testers, that helps.
This might be seen as off-topic, since I delved into talking about a video game mod on a software design article, but I hope my points still came across. To me, I see it as an example of what you're talking about here, but I might be coming off as weird.



  1. 2024
  2. 2023
  3. 2022
  4. 2021
  5. 2020
  6. 2019
  7. 2018
  8. 2017
  9. 2016
  10. 2015
  11. 2014
  12. 2013
  13. 2012
  14. 2011
  15. 2010
  16. 2009