A Lack of Logic
Microsoft released Windows XP on Oct. 25, 2001. That same day, in what may be a record, the company posted 18 megabytes of patches on its Web site: bug fixes, compatibility updates, and enhancements. Two patches fixed important security holes. Or rather, one of them did; the other patch didn’t work. Microsoft advised (and still advises) users to back up critical files before installing the patches. Buyers of the home version of Windows XP, however, discovered that the system provided no way to restore these backup files if things went awry. As Microsoft’s online Knowledge Base blandly explained, the special backup floppy disks created by Windows XP Home “do not work with Windows XP Home.”
Such slip-ups, critics say, are merely surface lapses-signs that the software’s developers were too rushed or too careless to fix obvious defects. The real problems lie in software’s basic design, according to R. A. Downes of Radsoft, a software consulting firm. Or rather, its lack of design. Microsoft’s popular Visual Studio programming software is an example, to Downes’s way of thinking. Simply placing the cursor over the Visual Studio window, Downes has found, invisibly barrages the central processing unit with thousands of unnecessary messages, even though the program is not doing anything. “It’s cataclysmic.It’s total chaos,” he complains.
The issue, in the view of Dan Wallach, a computer scientist at Rice University, is not the pointless churning of the processor-after all, he notes, “processing power is cheap.” Nor is Microsoft software especially flawed; critics often employ the company’s products as examples more because they are familiar than because they are unusually bad. Instead, in Wallach’s view, the blooming, buzzing confusion in Visual Studio and so many other programs betrays how the techniques for writing software have failed to keep up with the explosive increase in its complexity.
Programmers write code in languages such as Java, C and C++, which can be read by human beings. Specialized programs known as “compilers” transform this code into the strings of ones and zeroes used by computers. Importantly, compilers refuse to compile code with obvious problems-they spit out error messages instead. Until the 1970s, compilers sat on large mainframes that were often booked days or weeks in advance. Not wanting errors to cause delay, coders-who in the early days tended to be trained as mathematicians or physicists-stayed late in their offices exhaustively checking their work. Writing software was much like writing scientific papers. Rigor, documentation and peer-review vetting were the custom.
But as computers became widespread, attitudes changed. Instead of meticulously planning code, programmers stayed up in caffeinated all-night hacking sessions, constantly bouncing results off the compiler. Again and again, the compiler would spit back error messages; the programmers would fix the mistakes one by one until the software compiled properly. “The attitude today is that you can write any sloppy piece of code and the compiler will run diagnostics,” says SRI’s Neumann. “If it doesn’t spit out an error message, it must be done correctly, right?”
As programs grew in size and complexity, however, the limits of this “code and fix” approach became evident. On average, professional coders make 100 to 150 errors in every thousand lines of code they write, according to a multiyear study of 13,000 programs by Humphrey of Carnegie Mellon. Using Humphrey’s figures, the business operating system Windows NT 4, with its 16 million lines of code, would thus have been written with about two million mistakes. Most would have been too small to have any effect, but some-many thousands-would have caused serious problems.
Naturally, Microsoft exhaustively tested NT 4 before release, but “in almost any phase of tests you’ll find less than half the defects,” Humphrey says. If Microsoft had gone through four rounds of testing, an expensive and time-consuming procedure, the company would have found at most 15 out of 16 bugs. “That’s going to leave you with something like five defects per thousand lines of code,” Humphrey says. “Which is very low”-but the software would still have as many as 80,000 errors.
Software engineers know that their code is often riddled with lacunae, and they have long been searching for new technologies to prevent them. To manage increasingly distended projects like Windows, for example, they have developed a variety of techniques, of which perhaps the best known is component-based design. Just as houses are built with standardized two-by-fours and electrical fittings, component-based programs are built out of modular, interchangeable elements: an example is the nearly identical menu bar atop every Windows or Macintosh program. Such standardized components, according to Wallach, are not only good engineering practice, they are “the only way you can make something the size of Microsoft Office work at all.” Microsoft, he says, was an early, aggressive promoter of this approach-“it’s the single best engineering decision they ever made.”
Unfortunately, critics say, the components are often glued together with no real central plan-as if contractors tried to erect large structures with no blueprints. Incredibly, Humphrey says, the design for large software projects is sometimes “nothing but a couple bubbles on the back of an envelope.” Worse, for marketing reasons companies wire as many features as possible into new software, counteracting the benefits of modular construction. The most widespread example is Windows itself, which Bill Gates testified in an April session of the Microsoft antitrust trial simply would not function if customers removed individual components such as browsers, file managers or e-mail programs. “That’s an incredible claim,” says Neumann. “It means there’s no structure or architecture or rhyme or reason in the way they’ve built those systems, other than to make them as bundled as possible, so that if you remove any part it will all fail.”
The inadequate design in the final products, critics argue, reflects inadequate planning in the process of creating them. According to a study by the Standish Group, a consulting firm in West Yarmouth, MA, U.S. commercial software projects are so poorly planned and managed that in 2000 almost a quarter were canceled outright, creating no final product. The canceled projects cost firms $67 billion; overruns on other projects racked up another $21 billion. But because “code and fix” leads to such extensive, costly rounds of testing, even successful projects can be wildly inefficient. Incredibly, software projects often devote 80 percent of their budgets to repairing flaws they themselves produced-a figure that does not include the even more costly process of furnishing product support and developing patches for problems found after release.
“System testing goes on for almost half the process,” Humphrey says. And even when “they finally get it to work, there’s still no design.” In consequence, the software can’t be updated or improved with any assurance that the updates or improvements won’t introduce major faults. “That’s the way software is designed and built everywhere-it’s that way in spaceships, for God’s sake.”