Buggy Whipped (2002)

NO SURPRISE that the majority of readers who responded to the question posed in the March 16th issue of TQ about the poor quality of commercial software were people who developed the stuff. The real surprise was that, to a man and woman almost, they agreed. What few of them could agree upon, however, was what to do about it.

Users of commercial software were in a minority, despite the fact that programming flaws can cause serious security breaches in an organisation's computer network for malicious hackers to exploit. A recent survey by InformationWeek listed operating systems (eg, Windows, Macintosh or Unix) as the buggiest sort of software, with productivity applications (eg, Word or Excel) a close second (see chart). Downloading and installing the software “patches” for fixing security breaches each time a new bug is discovered costs the average organisation around $700 per PC and $900 per server. So even modest-sized firms can easily spend upwards of $1m every time a bug is found that threatens their security. And it is not as though such flaws are rare. In America, the Federal Bureau of Investigation found 63 new security holes in commercial software it tested during just a three-week period this spring.

In this article , we discuss various measures that organisations can take to protect themselves from intruders bent on exploiting software flaws. It would, of course, be better by far if the software itself were more rugged in the first place. Although most agreed that there was no such thing as bug-free program code, the consensus among readers who joined the online discussion on this topic was that few customers could afford really bug-free software.

The problem, as they saw it, was the complexity of modern software—especially operating systems and productivity suites. “Twenty, or even ten, years ago, software was actually reliable,” one software developer admitted. That was because the cryptic operating systems on desktop computers at the time ( CP/M and MS-DOS ) were far smaller and more tightly coded than today's graphical beasts. The software written for bigger machines used to be more reliable, too. Before IBM was forced to “unbundle” its software, computer makers controlled both the program code and the hardware it ran on—and could thus integrate them properly. That was one of the reasons why IBM 's mainframes and Digital Equipment's minicomputers had such a reputation for reliability.

Readers had no trouble identifying the two leading culprits. One was the practice of re-using chunks of old software for doing set things. “Over time, code-reuse leads to massively complex and prodigiously huge software programs, full of ‘magic code' that nobody understands or wants to touch,” said another programmer. Analysing such programs was more like archaeology than computer science. “They are full of ‘midden piles' and ‘rock strata' containing artefacts and fossils that once had a clear purpose but whose function is now lost to history.”

Flurry of upgrades

The other reason for complexity was the way software companies, facing slower growth in sales to new users, have rushed to add extra features to their programs—even before their existing code base has stabilised—in a bid to generate revenue by getting existing customers to buy upgrades. So, instead of getting more reliable with each passing version, programs have become ever more bloated and unstable.

Clearly, lots of users value new features more than reliability, or they would not continue to buy upgrades. But where customers insist on reliability—as they do with, say, the “compilers” used for actually developing software—then the code tends to be remarkably robust. As compilers are no more expensive than many of the programs designed for the mass market, the argument that consumers could not afford better quality software would seem disingenuous.

What to do about it? A common theme among forum members was that revising the terms that software publishers enjoy under copyright law was preferable to extending product-liability laws to cover the software industry—as the National Academy of Sciences in Washington, DC , has proposed. As one software developer noted, “you can only have product liability when there is a well-defined product—and the computer industry is too immature for that.” Instead, he wanted copyright protection applied only to software that operates according to its published specification. That may be not as draconian as it sounds. “The current quality of software is so bad that we can set standards low and still get a great improvement.”

Even so, other forum members thought it was going a bit nuclear. “Besides,” noted another reader, “software companies would simply turn over the job of writing ‘specifications' to Nostradamus, and that of documenting bugs to retired Enron auditors.”

But what if software makers had to print a “health warning” on their products, guaranteeing that no more than a certain number of bugs would be found within a year of the product's release? That might make customers pause before buying such a buggy piece of software. If they did so nevertheless, and more than the guaranteed number of bugs were reported, those with a valid sales receipt would be eligible for a refund proportional to the number of additional bugs.

That may not be entirely workable, but it is an interesting suggestion. The encouraging thing about the “lemon law” discussion was that a lot of thoughtful people within the software industry are aware that the current state of affairs is bad for business and cannot continue. The surprising thing was not how few, but how many, were actively seeking to change things for the better.