Wall Street Journal tech columnist Walter Mossberg recently wrote a column on defective computer systems in which he bemoans the bugginess of his PC software, and protests that "[Computers] should just work, all the time." In another recent, similar piece, San Jose Mercury News tech columnist Dan Gillmor accuses the "technical industry" in general of "[an] attitude toward reliability and customer service [that] has been scandalous."

Over the years, any number of other writers have sounded similar themes: Computer systems are too buggy, there's no excuse for a single defect in software, if programmers built bridges we'd be afraid to drive on them, and so on. In the view of this school, software defects are a moral issue, instead of simply a result of the well-known tradeoff between schedule, cost, and quality. For these writers, there is no tradeoff possible--defects are a moral failing, and a complete absence of defects must be assured, whatever this demand does to the cost and the schedule.

In case you suspect that this is a lead-in to a round of excuses on the part of another bug-plagued developer, let me tell you the tale of my first exposure to developing software for a trading floor. My client was a partnership that traded stocks with the partners' capital. In this case, the people who specified the software, the people who managed its development, the people who paid for its development, and the end users were all the same people! Thus, there was little question that any one of these groups was misrepresenting the other's interests in the development process.

Imagine my surprise when I showed an early version of my first project to one of the partners and he replied, "This is great, we'll start using it tomorrow."

Nonplused, I explained to him that this was merely a first cut, intended to make sure that we were on the same track as to what we were developing.

"Fine," he told me, "we'll keep working on it, but we can be making money with this version tomorrow."

"But, I've barely tested it!"

At this point, I received a lesson in economics. For a company creating an automated trading system, one measure of its quality would be the ratio of "good trades" (i.e., trades the designers intended the system to make) to "bad trades." If the average cost for a bad trade is $4,000, and the average benefit of a good one $2,000, then at the point the system would generate 67 percent good trades, it would be profitable. Any prerelease testing beyond that point is wasting money. Further testing may make the system more profitable, but by 67 percent, it is worth releasing. Thus we see that it is often inexcusable to delay delivering a piece of software in order to remove the last few bugs from it, a far cry from Mossberg's contention that it is inexcusable to ever have any bugs. And notice that in this case, it was the users who were forcing a developer to give them a relatively untested piece of software, against his instincts.

App(liance) Debugging

After the publication of Mossberg's aforementioned piece, one woman wrote to him, "I never have to reboot my refrigerator, no matter what I put in it." But a refrigerator does the same thing with all input-keeps it cold. It doesn't have to connect to your head of lettuce or leg of lamb, format your orange juice, recalculate the spiciness of your mustard, or spell check the labels on your capers. In fact, it keeps cooling even if you have nothing in it--something which we would consider a bug in a piece of software. A refrigerator is a fairly simple device, and a refrigeration engineer could explain the inner workings of one to Mossberg's correspondent in about half an hour. On the other hand, modern computer systems are among the most complex devices humans have ever constructed. To achieve a moderate understanding of the inner workings of Windows NT or Linux would take years.

Similarly, Gillmor contends: "The appliances we use at home do not crash." Really? In the two years since my family built our new house, our smoke detectors stopped working, our pipes leaked, the dryer failed to start, the stove has been repaired twice, the septic system backed up and flooded the washing machine, the grouting between many tiles developed cracks, the motion detection lights failed to function, and a floor buckled and had to be repaired. And we have been told, by friends with new homes, that we have had exceptionally few serious problems.

Gillmor says: "[Consumers] just don't want to consider the possibility that low prices can mean not-so-great service. People have to patronize the companies that provide quality, and have to be willing to pay more." But he doesn't consider that consumers might be well aware of this possibility, and could rationally choose to trade quality for price. Someone using an online brokerage might decide that saving $15 a trade is worth suffering the service being down for one hour a month.Why shouldn't a consumer make this tradeoff if she feels it is in her interest?

Even in the market most thoroughly dominated by Microsoft -- desktop operating systems -- consumers are able to make their own choices on quality in software every day. There are, after all, two major varieties of Windows on the market. Windows 98, the cheaper of the two, is much more prone to crashing than Windows NT, the more expensive. This fact is well publicized in reviews and advice columns. Yet consumers overwhelmingly opt for Windows 98. And shouldn't they have this option? Mossberg's actions, if not his words, say "yes"--it is obvious from the story of his crashes that he is using a consumer version of Windows, and not NT.

Related Articles

Gillmor, Dan. " Online Reliability Will Carry a Price," San Jose Mercury News, July 17, 1999.

Mossberg, Walter S. " I'm Tired of the Way Windows Freezes!" The Wall Street Journal, September 30, 1999.

Reader Response:

• Software is Too Buggy
  
• Less Room for Bugs in Shrinkwrapped Software
• Corporate Responsibility is the Key
• Perfect is the Enemy of Good Enough

These op/eds do not necessarily reflect the opinions of the author's employer or of Dr. Dobb's Journal. If you have comments, questions, or would like to contribute your own opinions, please contact us at editors@ddj.com.

1 | 2 | 3 | 4 | 5 Next Page

RELATED ARTICLES This Week's Developer Reading List This Week's Multicore Reading List A Structured, Unified Approach to Multi-Core and Many-Core Computing -- with Applications Logging In C++ : Part 2 OutSystems Updates Agile Platform		TOP 5 ARTICLES No Top Articles.