Skip to Content

The Trouble with Software

Revisting the software business flaws Charles C. Mann depicted five years ago.

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.

Shown above is the July 2002 feature in Technology Review, “Why Software is So Bad.”

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.

Keep Reading

Most Popular

How scientists traced a mysterious covid case back to six toilets

When wastewater surveillance turns into a hunt for a single infected individual, the ethics get tricky.

It’s time to retire the term “user”

The proliferation of AI means we need a new word.

The problem with plug-in hybrids? Their drivers.

Plug-in hybrids are often sold as a transition to EVs, but new data from Europe shows we’re still underestimating the emissions they produce.

Sam Altman says helpful agents are poised to become AI’s killer function

Open AI’s CEO says we won’t need new hardware or lots more training data to get there.

Stay connected

Illustration by Rose Wong

Get the latest updates from
MIT Technology Review

Discover special offers, top stories, upcoming events, and more.

Thank you for submitting your email!

Explore more newsletters

It looks like something went wrong.

We’re having trouble saving your preferences. Try refreshing this page and updating them one more time. If you continue to get this message, reach out to us at with a list of newsletters you’d like to receive.