Does It Have To Be This Hard?

In which Auntie rails at the sorry state of software—and what we can do about it.

• By Em C. Pea
• 09/01/2002

Instead, Fabio came home with the croissants to find me with my feet up on the keyboard, the computer off, and the newspaper open to the want ads. Was it too late, I wondered, to follow my mother’s advice and become a neurosurgeon?

You see, my computer told me this morning that it needed to install some updates to Windows. So I told it to do so and rebooted. Apparently, that was my fatal mistake, because the computer hung on boot. Two hours later, after numerous trips to safe mode, I’d finally isolated and removed the offending component and was able to get into my e-mail once again. By now lunch was lukewarm and I was steaming, thinking about the sorry state of software today.

It’s not like Auntie is the only one thinking about this, of course. In July, MIT’s respected Technology Review published an article by Charles C. Mann titled, “Why Software Is So Bad” (www.technologyreview.com/articles/
mann0702.asp). Mann argues that poor design and market pressures account for the fact that every shipping program has bugs in it and suggests that it’s time for either a big class-action lawsuit or government regulation.

Maybe so, though this bon vivant is always suspicious of attempts to fix things by more regulation. Since I’ve got lunch on my mind at the moment (and now Fabio is eating the kiwis without me!), let’s look at an analogy from the world of food. A quick survey of the meals most eaten at lunch would suggest that the state of food is bad. It’s not that all food is bad, or that we don’t know how to prepare good food; it’s that there is more of a market for cheap food. More people would rather eat a 39-cent taco than pay the premium for a five-star creation.

It’s the same way with software. There are techniques for producing software with far fewer bugs than most Windows users experience. But such techniques require more planning, more review and testing during the development process, and better follow-up when quality problems are found. As a result, they’re limited to problem domains where quality is more important than innovation or flashiness. For example, the software that handles reconciling check transactions between banks is largely trouble-free. But its development cycle is tightly constrained, and its features are limited to those necessary to do its job.

Even so, if we’re going to pay fast-food prices (I love a good analogy, don’t you?), it would be nice to get fast food rather than rotten fruit. It really seems like something is out of whack these days. What can we do about this? While waiting for the lawyers to awaken to the opportunities, it’s time to think about when to say, “no.” Pick a stable configuration and, except for necessary security patches, stick to it. Get serious about testing patches before you roll them out. Lock down the corporate desktops to prevent rogue installations. Tell your vendor reps you’ll upgrade when a new version offers improved stability rather than new features. Vote with your checkbook.

Of course, none of that will help those of us who live on the cutting edge, whose job it is to see which bits are safe to roll out to the masses. But I feel better now that I’ve vented, and sometime this week I’ll reinstall Windows and start over again. Meanwhile, Fabio says he’ll take me out to dinner, because the croissants seem to have vanished. See you next month!