< back to Writing and Presentations 

The last word: Why software still stinks

netWorker, Volume 6, Number 3 (2002)

Back in 1997, technology journalist Clive Thompson wrote that “Software is badly made. More than that, it is often horribly made. It is developed with the sort of irresponsible abandon that would be unconscionable if it were applied to bridge-building, car-making and possibly even plumbing.” Five years later, does he think the situation has gotten better? “If anything,” he says, “it’s gotten worse.”

There are good reasons why software is still so bad. For one thing, there’s the sheer complexity of the software itself. Windows XP has 45 million lines of code. At that scale, it’s nearly impossible to conceptualize all the ways in which one part of the program might interact with another part, or with another piece of software, and if you can’t conceptualize it, you can’t debug it. Not to mention the fact that studies have shown that programmers introduce about one error for every ten lines of code (mostly typos); that’s 4.5 million errors to catch in XP, plus all the new errors that get added in taking out the old ones.

Then, as everyone in the software industry will tell you, there’s the intense pressure to get products out the door. The DotCom boom only exacerbated the industry’s bad habit of shipping first and asking questions later. When your entire business strategy is built on being the first one in a particular market to build up “mindshare,” it’s less important that the product works well than that it works at all.

These aren’t easy problems to fix, and to a certain extent they’re not fixable at all. It seems unlikely that we’ll see an OS released anytime soon with a guarantee that it’s 100 percent bug-free. But although some experts think it will take major legal settlements against the largest software companies to make less-buggy releases an industry priority, some efforts to improve software quality are already making headlines. Bill Gates has deemed “dramatically reduc[ing]” the number of bugs in Microsoft products a corporate priority. And Kent Beck’s “extreme programming,” for all that its name makes it sound like something you’d watch on ESPN2, is getting real results: The iterative, testing-driven, pair-programming method reduces bugs by at least 15 percent.

But even if the industry were somehow to unite around the cause of producing software with fewer bugs and more security, most of the software you use today would still stink. Why? Because almost no one is building software with the average end-user in mind.

There are two major problems software development faces in this regard, and they both come from the developers themselves. First and most important is the nature of their job: A software developer lives and breathes complex code and subroutines, and it’s hard to shift out of that perspective to try to think like someone for whom software is just a tool to do other things rather than an end in itself. Think of it as the difference between your perspective on your car and your mechanic’s—except your mechanic generally isn’t the one making the decisions about what you’ll have to do at the wheel to make the car turn left.

One Linux programmer I know couldn’t understand the appeal of combined e-mail/calendar applications that send meeting invitations to your e-mail inbox. I explained that for most busy office workers, their e-mail inbox has become a sort of browser—a one-stop location to find all of their communications, meeting notices, to-dos and follow-up reminders. (See “E-Mail as Habitat,” in the September/October 2001 issue of interactions.) To him, this made no sense—calendars and e-mail were separate sets of tasks, and should have separate programs. Obviously, combination programs like Microsoft Outlook and Lotus Notes are the norm and my programmer friend is, in this case, in the minority. But the fact that the perspective of the average user literally made no sense to him seems to me paradigmatic of the problem that software development faces.

The second problem, which is an offshoot of the first, is that a culture of contempt for the user has developed inside the industry. My Linux programmer friend eventually came to a conclusion about the combination of e-mail and calendars. It wasn’t that he couldn’t understand the ways in which a non-technical person interacted with his or her work computer, but that people who like programs like Outlook and Notes are just plain stupid.

Indeed, the stupidity of the end user is perhaps the one thing in software development that everyone from a hardcore advocate of open-source software to passionate defenders of Microsoft agree on. Nathan Myhrvold, Microsoft’s former CTO, was quoted in July’s MIT Technology Review as saying: “Users are tremendously non-self-aware…Software sucks because users demand it to.” It’s hard to imagine a senior executive at a major bridge-building, car-making, or even plumbing-supplies corporation publicly blaming his customers for the failures of his product, but it’s not particularly surprising coming from someone in the software industry. The gap between developers and users in how they experience software has hardened into a chasm of contempt.

The losers, not surprisingly, are the users. We get software that’s bloated with features we don’t want and missing those that we do. We get software that provides ever more power and is increasingly hard to use. Usability experts are frequently involved in the rollout of new software products, it’s true, but they tend to be brought in at the end of a project, when they are limited in what they can suggest and what changes can be implemented. As one digital artist complained to me, “UI [user interface] design is not sexy, and coders don’t spend a lot of time on it.” But, as I’ve tried to suggest, part of the problem is that coders are being charged with UI design in the first place.

What can be done? Well, for one thing, software developers could ask their users what they want from the product, and check in with them throughout the development lifecycle. One of the major benefits of “extreme programming” is that it calls for an iterative design cycle with regular client reviews; by involving the client in the decision-making process from the beginning, it dramatically reduces the possibility that the project will need radical revision to meet client needs at the end of the work. Even if extreme programming isn’t right for a company, adopting an iterative process to check for usability would make it easier for companies to develop easy-to-use products. More importantly, bringing in non-programmer usability specialists and visual designers in the earliest part of the development cycle would mean that interface usability standards could be “baked in” as the project grows and changes. It would be nice to say that we can change the developer culture in which users are thought of as losers. But such a shift happens slowly over time. Until then, let’s let the coders worry about the bugs and give the people who will use the product more of a voice in how it appears on their desktop once it works. Maybe then, it won’t stink.

©2002 ACM  1091-3556/02/0900 
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

< back to Writing and Presentations