The poll that used to be on this page is dead. While it was up the ratio was always about the same as time went on: about 100:50:1 for stupid software : geekspeak (adcanced) button : smart software (wizards).

Also, the links to the Interface Hall of Shame are dead, this black ribbon will mark their passing. A partial mirror was set up by "bradster" on his homepage. I've saved it here. Wayback machine to the rescue!

The case for stupid software.

A terribly helpful friend of mine recently sent me to The Interface hall of Shame (Now 404-compliant), where there was a long steaming rant about Lotus Notes that contained an admirable amount of useful information about how to deal with Lotus' rather eccentric mail software. I've found this quite common in the past... when someone writes a long document describing how broken something is, they often let slip useful tricks and cues that you might not get from other sources. Check out their Lotus Notes rant (which some bright fellow saved at a mirror site) for a sterling example.

But that's not what I want to talk about today. No, it's a deeper problem that I've run into on this site, and that I run into every day dealing with software... particularly software designed to be used by naive users. They hammer at this again and again: users shouldn't have to read and understand technical error messages. As someone who has to deal with the result of this philosophy, that's just plain wrong.

The problem is simple: Software is stupid. We don't know how to make software smart enough that it's not still inherently stupid. It's only the synergy between the stupid software and the smart user that lets us get useful work done.

If you spend a lot of time and effort trying to make software smart, you end up making it more stupid:

  1. You increase the complexity of the system. This is inherently bad... every decision you make to test for something involves lines of code that may contain an error.
  2. Eventually you run into something that you didn't expect, and your carefully written code confidently tells the user something that's just plain wrong.
  3. You keep smart people from finding out what the real problem is.
I deal with a lot of relatively naive computer users every day in my job, and it's my firm belief that they are more capable than software developers think they are. Oh, sure, they may laugh at and make jokes about a program that produces error mssages like:

Logging into POP Server, [06:22:31 PM]
There has been an error transferring your mail. I said:
PASS <shhhh! Don't tell anyone.>
and then the POP server ( said:
ERR Bad Login

But that's more useful than some piece of software that tries to be smart.

A sterling example of a program that tries to be so smart it slips in its own drool is Windows Dialup Networking. It will happily reject the server's request for plaintext encryption [1] if you leave the default settings alone... which is fine... but then it pops up a message implying that the server rejected your login. Actually it gives you the same message no matter what went wrong. When you run into situations like this a few times, you'd kill for a message like "shhhh! Don't tell anyone".

It's like dealing with a injured animal. It can't tell you where it hurts, so you have to guess why it's not eating, why it's curled up in the corner pulling its fur out. And the smartest software that we have is nowhere near as smart as your average hamster or gerbil. But software has a significant advantage over your sick hamster... it can tell you precisely what went wrong, even if it can't tell you why.

So if DUN came with a dialog like:

Logging into RAS Server, [06:22:31 PM]
Login failed: Server requested plain text authentication, User requested CHAP or MS-CHAP.

you would still deliver the message "login failed", but you'd also tell the user why, and give him a chance of fixing the problem.

Now at this point the "smart software" advocate goes "OK, the problem is the software isn't smart enough! What we want to do is something like this":

Login failed: Server is not allowing encrypted (CHAP or MS-CHAP) authentication. To allow plain text authentication for this session or all sessions, select the "Login Wizard" button.

The problem here is that now instead of a simple dialog, you have a login wizard program with the associated extra disk space, and memory requirements, and bugs, and you end up with Windows NT 4.0 having several "Final Year 2000 hotfixes and services packs", and Windows 2000 requiring a minimum of 128M of RAM to run adequately, and skyrocketing RAM prices as the demand goes through the roof.

2003 update: ram prices came down, but now a gigabyte is considered reasonable, so you're still paying as much as the rest of the computer put together just for memory, and your video card's got more RAM than a typical desktop did in 1999.

Oh, it's only one program. You won't mind one more Wizard. It's only going to delay the release of the software by another day... but there's no end to the problem. There's always another failure mode the developer didn't anticipate. There's always another new server or new API change or plugin that didn't exist when the product shipped.

And finally, you end up with 6 or 7 different GUIs to do the same job, with different options in each. Dialup networking is already so far down this slippery slope its had its legs eaten off by the Mighty Sarlak... depending on how you start it up you can find the same information on multiple screens, some of which can't be reached except by going back to your original DUN icon and doing something different to it. Each individual choice made sense to the programmer who was trying to write a smarter program, but together they create a labyrinth of trapdoors and poorly marked exits that even experts get lost in.

Isys Information Architects themselves point out that Windows has at least a half a dozen different "Open File" dialogs. What they're missing, and all the "Smart Software" advocates are missing, is that this is the inevitable result of having too many people trying to write software that's smart enough that the user doesn't have to think... and failing.

The alternative is to write stupid programs that don't take control, that tell the user where it hurts, when it hurts. You don't have to shove this in the user's face, you can make the extended error dialogs optional, but they need to be there...

But be careful. There's another trap waiting for software that does this.

Some software has a diagnostic mode, an "Advanced" or "More Information" option. I call this the "Geekspeak button". The problem is that far far too often these buttons either say the same thing as the dialog box they're attached to, just using more words... that is, they're still trying to write smart software... or they contain gibberish impenetrable to even the most determined geek... the guy writing this code is writing it to help him debug his software, not to help other people configure it correctly.

For example, the "Windows NT Geekspeak button" is the logfile. Sometimes it's useful, but all too often the logfile contains messages like "the serial driver failed to load... the error code is in the data" (followed by 6 lines of hexadecimal noise). For the driver writer with his data structures bluetacked to his cubicle walls, this is great. For the guy trying to help some poor user with his modem, it's worthless.

In Windows this happens because "Smart Software" has yet another problem. This one's not really restricted to Windows, but they really pioneered this failure mode and they're the #1 source of it. Let's say you get some failure condition that started three layers deep in nested drivers and libraries. At each level instead of passing up "serial port failed to generate an interrupt" they each replace the error code with something that the author thought would be more helpful to the layer above. They have to: there's no central "error message" authority, and they're trying to save space [2] so they don't want to pass up a plain english description of the problem. The result is your "Geekspeak" button gives you a bunch of apparently random letters and numbers nobody can figure out without the source.

Outside of Windows, communication protocols often have the same problems. In the examples on this page email protocols like POP (above) or SMTP (in this error message from the Interface Hall Of Shame) generally deliver a textual note with each error condition that the program can pass on to the user. Sometimes these messages contain jokes, like the "Polite People" message [3]. But most of the time they provide some clue as to what might be going wrong. If the programmer didn't anticipate an error at that point (or even if he did, because the error may have some unexpected cause) there's something they can tell the user which might be more useful than "It hurts".

The PPP protocol, on the other hand, is binary, with binary error codes and little human-readable information. So when something goes wrong on the server (a log file fills up, a disk fails, a file gets renamed) the software simply has to pick the most appropriate response and stick it in the return packet.

So, for software authors:

  1. Don't assume that you know everything that might possibly fail.
  2. Don't be afraid of telling the user when you may have made a mistake.
  3. Don't duplicate effort. If there's already a way to configure the software, just direct the user to it... don't write a new one.
  4. Don't guess. If you don't know what went wrong, tell the user, and give him as much information as you can about what went wrong as you can.
  5. Be verbose. Be positively chatty. Design protocols so the program at the other end can tell the user what went wrong, or if it can't figure it out at least tell the user what YOU said was wrong. [4]
And for users: don't put up with stupid smart software. If you can't make head or tails of what went wrong from the error message, tell the company that wrote it. If it's too technical, say so. If it's simple, but wrong, tell them that too. If it's stupid, though... if it sounds ridiculous... but it still tells you what really went wrong, then thank your lucky stars that the programmer trusted you to see his mistake.

Because, let's face it, people should find computers ridiculous. We're still at the "stanley steamer" stage in the development of this technology. Given how primitive these machines are, "unprofessional" error messages that expose the leaking oil and the hiss of escaping steam are a lot more professional than arrogant ones that assume all users are incompetent and barely literate.

-- Peter da Silva, Houston, October 1999

That is, sending the actual text of the password over the phone line instead of exchanging secrets. This sounds dangerous, but it's actually fairly common for dialupservers. Some of the mechanisms used to exchange secrets have had security holes discovered in them (again, complexity is a problem) and intercepting a high speed modem connection is actually quite hard.
We have seen the results of trying to save space in venerable old COBOL programs that saved 2 characters in their date formats. Or even new C programs filling in fixed length text boxes... how many Y2K patches have YOU had to deal with so far?
As someone reading this page pointed out, Eudora gets full marks for telling the user what went wrong, and no marks for being non-compliant or obsolete. Dumb software copes with changing standards and programmer mistakes better than smart software.
Pretend your software is a test pilot talking though its final fatal crash to the cockpit voice recorder, so the next guy will know what killed it.