I <3 Steve McConnell*
Coding Horror
programming and human factors
by Jeff Atwood

September 27, 2004

The Rise and Fall of Homo Logicus

Of all the professional hubris I've observed in software developers, perhaps the greatest sin of all is that we consider ourselves typical users. We use the computer obsessively, we know a lot about how it works, we even give advice to friends and relatives. We are experts. Who could possibly design software better than us superusers? What most developers don't realize is how freakishly outside the norm we are. We're not even remotely average-- we are the edge conditions. I've often told program managers: if you are letting me design your software, your project is in trouble.

In The Inmates Are Running the Aslum, Alan Cooper labels this phenomenon Homo Logicus:

Homo logicus desires to have control over things that interest them, and the things that interest them are complex, deterministic systems. People are complex, but they don't behave in a logical and predictable way, like machinery. The best machinery is digital, because it can be the most complex, sophisticated, and easily changed by the programmer.

The price of control is always more effort and increased complexity. Most people are willing to make a moderate effort, but what differentiates programmers from most people is their willingness and ability to master extreme complexity. It is a satisfying part of the programmer's job to know and manage systems composed of many interacting forces. Flying airplanes is the archetypal programmer's avocation. The cockpit control panel of an airplane is packed with gauges, knobs, and levers, but programmers thrive on those daunting complexities. Homo logicus finds it fun and engaging, despite (because of!) the months of rigorous study required. Homo sapiens would rather ride along as passengers.

For Homo logicus, control is their goal and complexity is the price they will pay for it. For normal humans, simplicity is their goal, and relinquishing control is the price they will pay. In software-based products, control translates into features. For example, in Windows 95, the "Find File" function gives me lots of control over the procedure. I can specify which area of my disk to search, the type of file to search for, whether to search by file name or by file contents, and several other parameters. From a programmer's point of view, this is very cool. For some extra up-front effort and understanding, he gets to make the search faster and more efficient. Conversely, the user's point of view is less rosy because he has to specify the area of the search, the type of file to search for, and whether to search by name or contents. Homo sapiens would gladly sacrifice the odd extra minute of compute time if they didn't have to know how the search function works. To them, each search parameter is just another opportunity to enter something incorrectly. The probability of making a mistake and the search function failing is higher, not lower, with the added flexibility. They would gladly sacrifice all that unnecessary complexity, control, and understanding in order to make their job simpler.

Homo logicus are driven by an irresistible desire to understand how things work. By contrast, Homo sapiens have a strong desire for success. While programmers also want to succeed, they will frequently accept failure as the price to pay for understanding. There's an old joke about engineers that gives some insight into this need to understand.

Three people are scheduled for execution: a priest, an attorney, and an engineer. First, the priest steps up to the gallows. The executioner pulls the lever to drop the hatch, but nothing happens. The priest claims divine intervention and demands his release, so he is set free. Next, the attorney takes a stand at the gallows. The executioner pulls the lever, but again nothing happens. The attorney claims another attempt would be double jeopardy and demands release, so he is set free. Finally, the engineer steps up to the gallows, and begins a careful examination of the scaffold. Before the executioner can pull the lever, he looks up and declares, "Aha, here's your problem."

Cooper goes on to list a few more traits of Homo Logicus:

  • trades simplicity for control
  • exchanges success for understanding
  • focuses on what is possible to the exclusion of what is probable
  • acts like a jock
Pity the poor user, merely a Homo Sapiens, who isn't interested in computers or complexity; he just wants to get his job done.

Anybody can build a complex application that nobody can figure out how to use. That's easy. Building an application that's simple to use.. well, now that takes actual skill. I'm not sure you need high priced interaction designers to achieve this goal, but you do have to stop thinking like Homo Logicus-- and start thinking like Homo Sapiens.

Posted by Jeff Atwood    View blog reactions
« Weeding out the Weak Developers with J2EE
Why Your Code Sucks... and Mine Doesn't »
Comments

Indeed - who was it who first observed that making things complex is a simple task, while making things simple is complex?

Dominic Cronin on September 28, 2004 3:19 AM

I think that you're falling into the same trap that Alan Cooper has been for years. While programmers clearly interact with software on different footing than other users, it's well within the realm of the possible for programmers to get outside their own heads, listen, and think like end users. We are not one-dimensional automotons.

Jekke on September 28, 2004 9:37 AM

I don't like what Alan Cooper proposes, which is to do ALL interaction design before beginning coding. What's this, a return to the waterfall, except that we're doing "interaction design" instead of requirements? That's proven not to work.

Are the points he raises good? Yes. Is his proposed solution comical in its naivety? Yes again.

Darrell on September 28, 2004 10:00 AM

"Indeed - who was it who first observed that making things complex is a simple task, while making things simple is complex?"

I'm thinking of UNIX and LINUX in particular. How many years have they had to develop a decent UI? 20? 25? And counting. It's a hard problem, and developers aren't good at it. Linux is the hardest of the hard core developers and they arguably suck the most at it. Which is kind of what I was saying.

"We are not one-dimensional automotons."

Well, like most generalizations, it exists because it's true *most of the time*. Many developers are terrible at UI design, largely because they can't relate to "normal" users. Is it possible for developers to transcend this limitation and moonlight as UI designers? Sure. But bear in mind this is additional work above and beyond traditional software engineering skills, which is quite complicated already. It's a very full plate, which is why I like to see a division of labor. Developers of course should have input, but only those developers who have the discipline to realize that they are NOT representative users!

It is something I wish more developers would study and cultivate (buy them a copy of Krug's Don't Make Me Think!), because it's a huge deficiency shared by almost all the developers I've known.

Jeff Atwood on September 28, 2004 7:13 PM

"What's this, a return to the waterfall, except that we're doing 'interaction design' instead of requirements? That's proven not to work."

It's a good point, and I've seen it fail in exactly this way. You have to do mini-cycles, and overlap with UI design quite a bit. There's usually lots of up-front project work to do anyway: researching third party tools, writing proof of concept code for tricky parts, back end design, etc.

Jeff Atwood on September 28, 2004 7:24 PM

Though I get paid to do some programming work, I usually build a UI first in all projects I do. I make the UI work and function for what is needed and then I may go back and rework the code to be slightly more productive.

I know this is a backwards approach and it's not the best method simply because I have numerous old projects that only have a UI shell and no actual value as a program. Sure it looks pretty but that's about it. Then again I've always made little helper apps that would get some of my work done quicker, I never design full blown ERP packages or CRM suites (though I've been tempted to recently).

I can say that it's difficult to think like an end user but even then a developer typically cannot find all of the problems a typical end user can.

A solution to this would be to get friends and family to be your beta testers. I may be the only one who is basically employed as my family and friends personal PC Repair Shop so I figured it should be time that some of them paid me back. How can they do that? Beta testing. Since they already prove they can break their OWN PC, I can give them an application and let them do what they do best. It's the least they could do since they never offer anything in return and expect me to cater to their every computer-related whim.

Jeremy Brayton on September 29, 2004 1:44 PM

I remember the last job interview that I had - after the interview (they were sure they were going to hire me) they said something along the lines of "you shouldn't undercut yourself like that. You might not know that most users have no idea what Linux is, and even the better half of them think it's the company that made the router they have at home for their son's xbox."

Dave on July 28, 2007 11:42 PM

How were you undercutting yourself?

deworde on November 8, 2007 4:33 AM

"It's well within the realm of the possible for programmers to get outside their own heads, listen, and think like end users."
Problem is, they normally end up thinking like they think users think; or worse, thinking like they think users *should* think.
Type A: "The user is such a moron that he needs a cute little paperclip to show him what to do."
Type B: "The user should want to learn at least 5 new commands before opening a document and typing it."

deworde on November 8, 2007 4:36 AM

This is me, all the way. I look into X10, decide that it isn't flexible enough, decide to completely rewire the house to my own standards. The house that I don't own yet, and probably never will.

However, I disagree that we are willing to sacrifice simplicity, we want more control -and- more simplicity.

UNIX is simple, not in the sense that the end-user might imagine, not that it's simple to use, but that it's simple to understand, and was simple to design and implement. It's big, but it's made of lots of tiny, simple parts.

Windows is big, and made of big parts. Big parts that don't let you take them apart to see how they work.

We don't desire control, we desire things to be inspectable. We can't imagine using things without knowing how they work. We can't believe that people drive cars/use microwaves/browse the internet/etc, without fully understanding what's going on. How are you supposed to fix it when something goes wrong?!?

Knowledge is power, it's freedom, it's fun!

lotyrin on December 13, 2007 1:59 PM

Yes, I realise I contradict myself a bit there. :)

lotyrin on December 13, 2007 2:00 PM

lovely colour

orange on December 14, 2007 2:46 AM

very lovely (captcha) colour

very orange on December 31, 2007 3:30 AM






(no HTML)


Verification (needed to reduce spam):


Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved.