Book excerpt: Why software SUCKS

This article is excerpted from Why Software SUCKS... and what you can do about it, with permission of Addison Wesley. © Copyright Pearson Education. All rights reserved.

Why Software SUCKS... and what you can do about it
Where we came from

The designers of the earliest computer programs didn't care about making their products easy to use. Solving the computing problem at hand—for example, dealing with a printer to make the words come out properly on paper—was so difficult that no one had time or money left over for making a user's life easier. A computer's thinking time was enormously expensive, much more so than the user's time. Forcing the human user to memorize complicated commands instead of using computer power to provide a menu listing them made economic sense. The relative costs are now reversed, but almost everyone in the industry older than about 30 grew up in that type of environment. It can't help but shape our thinking today, no matter how hard we try to leave it behind. Think of your older relatives who grew up in the Great Depression of the 1930s, who even today can't bear to throw away a sock with only one hole in it.

Like driving a car in the early years of the twentieth century, early users expected computers to be a pain in the butt, and we were rarely disappointed. Almost all users were programmers themselves. Few of them felt the need, or often even the desire, to make things easier. We accepted the difficulties—the rationed computer time, the arcane commands, the awful documentation—as those motoring pioneers accepted hand-cranked engines and constant tire punctures. It was the best anyone had. We were happy to get our important computing jobs (tabulating the census, cracking enemy codes) done at all, as they were happy to stop shoveling horse manure out of the barn every day. We liked fiddling with our programs, using them in ways their designers never intended, as the early motorists liked tinkering with their engines. If someone had told Henry Ford that his Model T needed a cup holder, he'd have laughed in that person's face.

There was a feeling in those days that making programs easy to use was just plain wrong. If a program was hard to write, it should be hard to use so that only those who had proved themselves worthy through intellectual struggle could benefit from the programmer's effort. I remember, with surprising fondness even today, the pride I felt on discovering that the command to print a document on the first major computer system I ever used (1975, freshman year in college) wasn't Print or P, but rather, the letter Q, since you were placing the document in a queue to be printed. I had learned a magic word. I was becoming one of the elect. I was smart!

But as hardware got cheaper, and computers moved from the air-conditioned glass rooms attended by high priests to the workbenches of geeky hobbyists and then to the desktops of individual employees and the homes of real people, they had to become easier to use. So the developers of applications had to start putting time and money into designing a program that users could actually use. Why hasn't it worked?

Why it still sucks today

The piece of a computer program that deals with the human user—getting commands and input data from him, displaying messages and output data to him—is known as the user interface. As with many areas of computing, user interface design is a highly specialized skill, of which most programmers know nothing. They became programmers because they're good at communicating with a microprocessor, the silicon chip at the heart of the machine. But the user interface, by definition, exists to communicate with an entirely different piece of hardware and software: a live human being. It should not surprise anyone that the skill of talking with the logical, error-free, stupid chip is completely different from the skill of talking with the irrational, error-prone, intelligent human. But the guy who's good at the former is automatically assumed to be good at the latter. He's usually not, and he almost never realizes that he's not. That's what causes programmers' user interface designs to suck, at least from the standpoint of the poor schmoe that's stuck using that piece of junk.

How does this happen? Programmers have to have a certain level of intelligence in order to program. Most of them are pretty good at dealing with the silicon chip; otherwise, they get fired very quickly and encouraged to take up another profession in which they might possibly benefit society, such as roofing. How can they turn into lobotomized morons when designing a user interface? For one simple reason, the same reason behind every communication failure in the universe: They don't know their users.

Every programmer thinks he knows exactly what users want. After all, he uses a computer all day, every day, so he ought to know. He says to himself, "If I design a user interface that I like, the users will love it." Wrong! Unless he's writing programs for the use of burned-out computer geeks, his user is not him. I tell my programming students to engrave on their hearts, along with the phrases "Garbage In, Garbage Out" and "Always Cut the Cards," Platt's First, Last, and Only Law of User Interface Design:

Know thy user, for he is not thee

To take the simplest example, consider a personal finance program, such as Quicken or Microsoft Money. These get used for a few hours every couple of weeks. A user won't—can't—remember as much of the program's operation from the previous session as she would for an application she used every day. She will therefore need more prompting and guidance, which an all-day every-day user (such as the programmer) finds intrusive and annoying. It's impossible for a programmer to put himself into the shoes of such a user. The programmer knows too much about the program and can't conceive of anyone who doesn't.

Because they're laboring under the misconception that their users are like them, programmers make two main mistakes when they design user interfaces. They value control more than ease of use, concentrating on making complex things possible instead of making simple things simple. And they expect users to learn and understand the internal workings of their programs, instead of the other way around. I've done them both, and I now repent the error of my foolish younger ways.

Control versus ease of use


Here's an example of doing it wrong. AT&T directory assistance was once simple and easy. You'd ask for someone's number and the automatic voice would say, "The number you requested is 555-1212. Please make a note of it." If you stayed on the line, it'd repeat the number so that you could be sure you'd written it down correctly. Simple. Easy. Impossible to screw up. Good. Then AT&T added the capability of automatically dialing the number for you. They'd say, "The number you requested, 555-1212, can be automatically dialed for an extra charge of 50 cents. Press 1 to accept and 2 to decline." The simple thing was as easy as ever, and the newer, more powerful feature was available to those who wanted it enough to pay for it. Anyone who didn't like the new feature could simply hang up. Then some idoit [sic, see Chap. 1, page 14] had an absolutely awful idea. The last time I tried AT&T directory assistance, it said, "The number you requested can be automatically dialed for an extra charge of 50 cents. Press 1 to accept and 2 to decline." It wouldn't give me the number until I entered my choice. I had to take the phone away from my ear, visually reacquire the keypad (which gets harder after age 45 or so), put down the pencil I was holding in my other hand to write down the number, press the correct button, pick up the pencil again, and put the phone back to my ear. Only then would it tell me that the number was 555-1212. The complex, powerful operation is possible, but the simple operation is no longer simple. The designer of this system clearly valued control over ease of use, but I guarantee that his users don't. Whoever inflicted this on the world should be forced to do it 500 times every day. He'd shoot himself by the end of a week.

I don't care how your program works

The second mistake programmers make when they design user interfaces is to force users to understand the internal workings of their programs. Instead of the programmer adjusting her user interface to the user's thought processes she forces the user to adjust to hers. Furthermore, she'll usually see nothing wrong with that approach. "That's how my program works," she'll say, puzzled that anyone would even ask why her user interface works the way it does.

Here's an example of what I mean. Open Windows Notepad, or any other type of editor program, and type in any random text. Now select File, Exit from the main menu, or click on the X box in the upper right of the title bar. You'll see the message box shown in Figure 1-1.

Figure 1-1Notepad asking the user whether to save changes
Figure 1-1

Notepad asking the user whether to save changes

What exactly is this box asking us? It seems to be saying that some file changed, but I haven't seen any file anywhere. What the hell does "save the changes" mean?

The answer is that Notepad usually edits documents (called files by computer geeks) which live on your computer's hard drive. When you open a document, Notepad copies it from the disk into the computer's memory. As you add or remove text by typing, the program changes the contents of this memory copy. (In this example, we didn't open an existing document, but the program created a new one in memory, giving it the name "Untitled".) When you're finished working on the document, the program has to write the memory copy back to the disk, an operation called saving the file. Otherwise, the work you've done will disappear, and you'll get very angry.

The programmer wrote the program this way (copy the document from disk to memory, make changes on the memory copy, and write it back to disk) because that was easiest for her. And it's not a bad way to write a program. Reading or writing characters from the disk (spinning iron platters with movable parts) is roughly a thousand times slower than doing it in memory (electrons moving at the speed of light), so this probably is the best way for this simple program to work internally.

But the programmer's user interface exposes these workings directly. How can that be bad? She's forcing you to understand that she's written the program this way. You shouldn't have to know or care about her program's internal workings to use it successfully, as you shouldn't have to know or care whether your car's engine uses fuel injection or a carburetor in order to drive it.


Where we are and what you can do

Where does that leave us poor users? To summarize my points so far:

  1. You are not dumb. User interfaces really do suck, and they shouldn't.
  2. They suck because they're designed by programmers, who don't realize that their users aren't like them.
  3. Because of Point 2, their interfaces are intentionally complex, and they expect you to like dealing with that, which you don't (see Point 1).


So the next time you see a badly designed user interface, stop and look at it. Play for a while; figure out exactly and specifically why you don't like it, and what would make you happier. Post a notice about the bad design on a "Hall of Shame" Web site that exists for this purpose. This book's Web site,, would be a good place to start. Then send e-mail to the application company, showing them your public exposé. The more stupid you've caught them being, the more it'll gall them to see it publicized. Then they might, might finally get it through their heads that their users aren't themselves.

© Copyright Pearson Education. All rights reserved.

Listen to a podcast with the author of Why Sofware SUCKS, David Platt, as he explains why programmers write bad software and what buyers can do about it. Duration: 14 minutes

Do you agree or disagree? Do you have another example or perhaps a counterexample? Post your comments here.

Why Software SUCKS...and what you can do about it

By David S. Platt

Published by Addison-Wesley Professional

ISBN: 0321466756; Published: 9/27/2006; Copyright 2007; Edition: 1

Copyright © 2006 IDG Communications, Inc.

Shop Tech Products at Amazon