The Trouble with Software

When you drive a new car off the lot, you can assume it won’t need repairs for a long time (unless you crash it). But when you install a Microsoft program on your computer, you assume that your next step will be to download security patches and bug fixes. A July 2002 feature in these pages asked why software is so bad and wondered whether programmers shouldn’t be held to the same quality standards as other workers equally critical to our industrial civilization, such as mechanical, electrical, and civil engineers.

That unresolved question has inspired one of software’s leading lights to propose a radical answer. As Scott Rosenberg reports in this issue (see “Anything You Can Do, I Can Do Meta”), Charles ­Simonyi, Microsoft’s chief architect during its formative years, has started a company dedicated to developing an entirely new approach to writing code. Though it’s unclear whether he’ll succeed, it is clear, as Charles C. Mann wrote five years ago, that the software business has singular problems.

Programming experts tend to agree that … disasters are distressingly common. Consider the Mars Climate Orbiter and the Polar Lander, both destroyed in 1999 by familiar, readily prevented coding errors. But some argue that software simply cannot be judged, measured, and improved in the same way as other engineering products. “It’s just a fact that there are things that other engineers can do that we can’t do,” says Shari Pfleeger, a senior researcher at the Rand think tank in Washington, DC, and author of the 1998 volume Software Engineering: Theory and Practice. If a bridge survives a 500-kilogram weight and a 50,000-kilogram weight, Pfleeger notes, engineers can assume that it will bear all the values between. With software, she says, “I can’t make that assumption–I can’t interpolate.”

Moreover, software makers labor under extraordinary demands. Ford and General Motors have been manufacturing the same product–a four-wheeled box with an internal-combustion engine–for decades. In consequence, says Charles H. Connell, former principal engineer of Lotus Development (now part of IBM), they have been able to improve their products incrementally. But software companies are constantly asked to create products–Web browsers in the early 1990s, new cell-phone interfaces today–unlike anything seen before. “It’s like a car manufacturer saying, ‘This year we’re going to make a rocket ship instead of a car,’” Connell says. “Of course they’ll have problems.” …

It is difficult to overemphasize the uniqueness of software’s problems. When automotive engineers discuss the cars on the market, they don’t say that vehicles today are no better than they were ten or fifteen years ago. The same is true for aeronautical engineers: nobody claims that Boeing or Airbus makes lousy planes. Nor do electrical engineers complain that chips and circuitry aren’t improving. As the engineering historian Henry Petroski suggested in his 1992 book The Evolution of Useful Things, continual refinement is the usual rule in technology. Engineers constantly notice shortcomings in their designs and fix them little by little, a process Petroski wryly described as “form follows failure.” As a result, products incrementally improve.

Software, alas, seems different. One would expect a 45-million-line program like Windows XP, Microsoft’s newest operating system, to have a few bugs. And software engineering is a newer discipline than mechanical or electrical engineering; the first real programs were created only 50 years ago. But what’s surprising–astonishing, in fact–is that many software engineers believe that software quality is not improving. If anything, they say, it’s getting worse. It’s as if the cars Detroit produced in 2002 were less reliable than those built in 1982.