radiant.matrix

There’s a book by David S Platt titled Why Software Sucks… and What You Can Do About It. Sounds intriguing, no? Mr. Platt has placed a sample chapter online, so I took the opportunity to peruse it. It didn’t take me long to realize that Mr. Platt is approaching this problem all wrong:

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? 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, 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. — Sample Chapter of Why Software Sucks

There’s just so much wrong with this… (read on after the fold)

The first flawed assumption that Mr. Platt makes is that programmers who aren’t good at programming rapidly get fired. It’s simply not true. Programming ability and performance are so hard to objectively measure that mediocre and poor programmers can — and regularly do — hide inside massive development organizations for months or even years before they are discovered. Some times they’re never discovered.

Unfortunately, the vast majority of users to whom Mr. Platt is attempting to communicate aren’t frustrated by the small applications that are written by a handful of good programmers. Rather, they’re irritated by the works of the major development houses: Microsoft, IBM, Adobe, etc.. These are exactly the places where bad programmers find it easiest to hide.

The second flawed assumption of Mr. Platt is that UI designs are bad because programmers are assuming what the users want. That’s likely true on occasion, but my experience doesn’t bear that out. Programmers don’t know what users want for two reasons:

1. Users don’t know what they want. It’s true. Users are seldom self-reflective enough about their computing habits to describe what the ideal experience for a given interface would be. All most users can do is explain what they don’t like.

2. The users’ desires never make it to the development team. There are many possible reasons for this; most commonly it’s some combination of poor communication between management and the programming team, poor communication between users and their representatives (which is usually the reps not listening), and a complete lack of mechanism for programmers to ask questions.

The question that Mr. Platt should be addressing, then, isn’t “how do we fix our programmers to be more like users?” It should be, instead, “how can we get get programmers to understand what users really want?” The answer is not to change how the programmer thinks, in general; the answer is to change the environment in which the programmer works.

As stated above, it’s rare to find a user that’s so introspective as to be able to tell us accurately how he or she wants an interface to work. Because of this, when projects force their users to design the interface, the users find out that it sucks just as much as any other approach. This is because it’s hard to know what one wants without a base of comparison.

In other words, it’s hard for a user to say “this function should work this way” when they haven’t tried any other way. Users are just as short-sighted as programmers. It’s far easier for a user to actually use a feature, then say “this function should work this way instead of that way.”

This can be used to a software project’s advantage: build interfaces early and let users poke at them. Listen to what they don’t like, and try to correct that behavior; then let the users poke at it again until your complaints are few enough. (I say “few enough” because usage is highly personal — you’ll never create an interface that no one dislikes.)

So what about the second issue? Management needs to have some programmers working as closely as possible with potential users of the product. The old “telephone game” experiment applies here: if you have users talking to representatives who talk to salespeople who talk to managers who talk to architects who talk to designers who talk to programmers (and that’s really what many large projects go through), you’re going to lose and pervert information.

Why does software suck? Not, as Mr. Platt seems to be suggesting, because programmers are “lobotomized morons when designing a user interface”; rather, it’s because the environment in which programmers work is not conducive to understanding what does and does not work for a given user group. Fix that, and software will suck a whole lot less.