Most popular commercial software for home and business use is extremely shoddy in design and construction -- difficult to use, unreliable, and uneconomical in its use of resources. Why are the standards of software quality so low? Are there any prospects for change?
The worst characteristics of popular commercial software are that each package is frighteningly complicated; that it breaks (crashing or behaving in nonsensical and inconvenient ways) when it exhausts some resource or when the user tries to do something that the programmer did not foresee; that its components are incoherent and even inconsistent; and that its behavior changes over time, depending on some obscure or invisible variable.
No one uses the full power of a large software system. Most people want software to do a small number of things perfectly and efficiently, whereas most commercial software is designed to do many different things awkwardly. Why the mismatch? Partly because different people want to do different things, so the market for a complicated software system is broader; partly because the maker can charge more for complicated software, even though it doesn't meet consumers' needs as well.
Most software breaks easily (and behaves badly when it breaks -- but that's another problem). Why? Basically, because the makers think that it's too much trouble (``not cost-effective'') to make it more robust. Once they have your money, they're not much worried about your trouble and the ensuing costs to you of coping with the problem.
A typical example: When a computer program needs to store some information, it attempts to reserve some space for that information in the computer's memory. Usually, this is unproblematical, but sometimes the computer is already remembering as much as it can and has no more space available, so the attempt to reserve space fails. If you or I were designing the program, it would not proceed until some steps had been taken to clear enough room in the computer's memory for the information we want to store. A widespread practice among software developers, however, is to ignore the failure and barge ahead with the attempt to store the information in the non-existent space. One possible result is that the program crashes. If your operating system is Windows, the consequences don't necessarily stop there, because Windows also often ignores memory-allocation failures; you may well get the Blue Screen of Death.
This is one of the more frustrating kinds of defects, because the usual reason for the memory-allocation failure is that your program has created a lot of information in the computer's memory without transferring it all to your hard disk; you have a large unsaved document in the word-processor or the spreadsheet, and when the program crashes you will lose some or all of it. Don't expect sympathy from the maker's technical-support team; they will tell you that the program wouldn't have crashed if your computer had more memory, which is technically true but ignores the point that it also wouldn't have crashed if the maker had done the job right to begin with.
Last December I received a bill that stated (incorrectly) that my account was more than ninety days overdue. It ended with these two computer-generated lines:
YOUR ACCOUNT MAY BE TURNED OVER TO A COLLECTION AGENCY
HAPPY HOLIDAYS!!
I was not amused.
This example shows that even a part of a program that does its job perfectly -- the part that generated the holiday greeting -- can fail completely when it is incoherently coupled with another program part -- in this case, the threat generator. The thoughtless combination of these two pieces converted what may have been intended as a pleasantry into an insulting sarcasm.
That's a small and superficial example of a pattern that occurs again and again in software development -- pieces that appear in isolation to be well-designed, but don't fit together well. Sometimes incoherence is a result of poor planning; more often the problem is that the people who have thought about how the pieces should fit together find that their development tools are not flexible enough to achieve the intended design -- just as the clerk to whom I complained assured me that it was impossible to prevent the billing system from printing misinformation and sarcasm. Even the makers of software sometimes feel that they cannot control it and are not responsible for its behavior.
One of the most frustrating things about software is that it doesn't always respond in the same way to the same user action. Sometimes pressing the Q key causes a Q to appear on screen; sometimes it means ``quit'' and shuts down the program. You can open a folder by moving the mouse pointer onto it and clicking twice -- unless, of course, you can't, because a double click means something else in this window or in this program or in this graphical user interface or with this mouse.
Perhaps some of this nonsense is inevitable, since the number of operations that one might want a computer to perform is so large that we can't very well provide a separate key or button for each one. But much of the state of a graphical user interface and other contemporary software is invisible, intrusive, and fantastically intricate.
Programmers aren't dumb, and even some managers are vaguely aware that something is amiss. These problems can be solved -- why aren't they?
One reason is that the intelligence of software designers is not always accompanied by thoughtful imagination and empathy. It is difficult for an expert to put himself in the position of most users of the software he writes, and harder still to imagine himself using that software regularly and repeatedly, and having to cope with its defects instead of reaching in to fix them.
However, most of the reasons for the ubiquity of bad software are economic.
For example, customers who try to comparison-shop for software often go by reviews in specialty magazines, which are often incompetent and tend to assign far too much weight to ``feature checklists,'' without regard to whether the features are well implemented, likely to be used, or related to the overall purpose of the software. Naturally, software makers respond to such reviews by loading up their products with badly implemented, seldom-used, irrelevant features, while doing nothing to make their programs simpler or more reliable.
Because the software industry changes very rapidly, managers are obsessed with minimizing ``time to market'' and with obtaining short-term advantages over other companies. Consequently, they take little interest in tools and methods that appear to slow down software development, even if the quality of the resulting product is higher and even if the methods will save time in the long run. The theory is that there will be no long run for companies that don't produce immediate profits.
This market-enforced short-sightedness results in spectacularly foolish evaluations of the work of programmers. For instance, the productivity of a software writer is frequently measured in ``lines of code,'' which makes exactly as much sense as paying a construction worker ten cents for each nail he uses.
Market forces obstruct the design and development of good software in many other ways as well. For instance, although software makers generally test their products before releasing them, they often find that it is not cost-effective to correct the defects that testing reveals. The problems that can be fixed quickly and inexpensively are dealt with before the product is marketed; the rest are set aside to be ``addressed in the next release.''
A software maker sometimes deliberately create incompatibilities and inconsistencies between its products and those of other companies, for ``customer control'' -- forcing customers who use one of the maker's products to adopt its entire product line.
However, the nature of the software market -- consumers, producers, and the relation between them -- is changing, mostly in ways that seem likely to favor consumers.
The Internet makes it possible to organize the development and distribution of a large software system as a volunteer, non-commercial, public-service project, sometimes called ``open-source'' projects (because anyone can inspect and contribute to the ``sources,'' the files in which programmers write out the instructions that the computer is to follow). Errors are detected and corrected much more rapidly in an open-source project, and programmers can use appropriate and effective tools and methods rather than those prescribed by market forces.
Open-source software is often distributed free over the Internet or for nominal amounts by non-profit organizations. From the customer's point of view, it's a lot like commercial software, only cheaper. The other major difference to customers is technical support, which is usually by e-mail or Usenet to the developers rather than by telephone to a customer-service representative.
Many software licenses try to protect the maker from liability for defects in their products, even when the customer uses the product for its intended purposes and follows the maker's instructions. American courts have begun to look critically at such efforts and to hold makers responsible for losses and damage that is directly traceable to defective software. If this trend continues, makers may adjust their thinking about the cost-effectiveness of their development practices.
For many years, customers were at a great disadvantage when buying computers and software because they lacked experience; they didn't know exactly what they were buying and found it hard to distinguish good products from bad ones.
Now there are many customers who have grown up with computers and have developed much more discrimination. They are increasingly aware of, and resentful of, the makers' techniques for marketing junk. As knowledgeable customers replace naive ones in the market, the forces that currently drive quality down will be greatly weakened.
I hope that software gets better, and I think that it might. What signs would indicate a trend towards higher-quality software?
Microsoft's series of Windows operating systems are prime examples of bad software, with all of the problems mentioned above compounded by the monopolist's natural indifference to the quality of his product. I expect Windows to begin its fall soon: Specialized versions may be hidden inside your cable-TV box or your car, but its days of dominance and high visibility on home computers and on the desktops and laptops of business people are numbered.
There are several open-source alternatives to Windows. The one that appears most likely to succeed is called Linux. The main obstacle to its success is that some applications that are widely used in business have gradually adapted to Microsoft's customer-control measures and so don't run under Linux; however, as those applications are revised, their makers will increasingly eliminate these adaptations and make their products available for Linux systems (and other non-Windows systems, such as Macintoshes). So Microsoft's fall will accelerate over time.
Another sign of a rise in software quality would be that programs use less of your computer's internal memory. Commercial software often demands twenty or fifty times as much memory as it actually uses. When I read the announcement on the box, ``requires 64 megabytes RAM,'' I generally know that the software uses perhaps a megabyte and fills up the rest of the memory that it demands with ``bloat'' -- unused icons, splash screens, and instruction sequences, often duplicated a dozen times. Programs contain bloat because editing it out would take some time and effort without adding any new features to the software -- so, from the maker's point of view, it is not cost-effective.
Customers, however, are getting sick and tired of having programs run out of memory and crash, and in increasing numbers they are making the connection with bloat and saying not ``My computer needs more memory,'' but ``Your software should use less memory.'' High-quality software does not treat any computer resource (memory, processor time, hard-disk space, screen space) as if it were free. In the absence of market forces, in fact, programmers have a proud professional tradition of trying to do more with less. A greater sense of professionalism among programmers would be another sign of a trend towards software of higher quality.
A summary of this conversation is available on the World Wide Web at http://www.cs.grinnell.edu/~stone/events/better-software/.
The Bad Software web site at http://www.badsoftware.com/ contains extensive discussions of software product liability from a legal point of view.
The Risks Digest, http://catless.ncl.ac.uk/Risks/, compiles reports and commentary on public dangers resulting from the use of defective computer software, ranging from the mildly humorous (a 105-year-old receiving a notice to enroll for kindergarten) to the positively frightening (a radiation machine, used for cancer therapy, that delivered several hundred times the expected dose of radiation under hard-to-trace circumstances).
The short essay ``Why computers aren't as fast as they used to be,'' at http://www.clock.org/~fair/opinion/software-bloat.html, is a professional programmer's account of the causes and effects of software bloat.
The Free Software Foundation, http://www.gnu.org/, supports the kind of public-interest development and distribution of software described here. The short essay ``Why software should not have owners'' at http://www.gnu.org/philosophy/why-free.html explains why.
There are many sources of information about Linux; ``Linux Online!'' at http://www.linux.org/ is one place to start. To see what the screen of a computer that is running Linux looks like in use, see the samples provided by the GNOME Project at http://www.gnome.org/screenshots/index.shtml.
Eric Raymond's widely read essay ``The cathedral and the bazaar,'' at http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html, contains a detailed discussion of the reasons why open-source software is likely to prevail in the market. For shorter accounts targeted to specific audiences, visit the Open Source page at http://www.opensource.org/.
For Bill Gates's recommendations on the management of software projects, see his column ``How to keep a good project on track? Here are 10 tips,'' at http://www.microsoft.com/billgates/columns/1998essay/9-9col.htm.
created May 4, 1999
last revised July 12, 1999