Defective Software Works
By: Watts S. Humphrey
Over the years, many people have written to me with questions about software quality, testing, and process
improvement. Jon Hirota asked how to get organizations to invest in software quality; John Fox
asked if I see a movement away from system test and toward quality processes; Bob Schaefer wondered
what I thought would happen in the area of software integration and testing; Dan St. Andre asked what
software development managers can do to encourage executive management to meaningfully address
software quality; and Pete Lakey wondered if and how the software community should use statistical
process control techniques. I won’t directly answer all of these questions but I will discuss these quality
and testing issues here and in my next column. While it has taken me an embarrassingly long time to respond
to these letters, they still raise a critical question: “How important is software quality and how
should quality practices change in the future?”
First, What Do We Mean by Quality?
While the classical definition of product quality must focus on the customer’s needs, in this and the next
column, I will concentrate on only the defect aspect of quality. This is because the cost and time spent in
removing software defects currently consumes such a large proportion of our efforts that it overwhelms
everything else, often even reducing our ability to meet functional needs. To make meaningful improvements
in security, usability, maintainability, productivity, predictability, quality, and almost any other
resources to other aspects of quality.
The functional and operational characteristics of a software product should and will continue to be important,
but that is where most people now focus, and there is little risk that they won’t continue to do so
in the future. If a product doesn’t have attractive functional content, it won’t sell, regardless of how few
or how many defects it contains. Unfortunately, many software groups treat the importance of functional
quality as an excuse to concentrate almost exclusively on product function and devote little attention to
better managing the defect problem.
While there is irrefutable evidence that the current “fix-it-later” approach to defect management is costly,
time consuming, and ineffective, don’t expect this to change soon. It is too deeply ingrained in our culture
to be rooted out easily. However, since I’m an optimist, I’ll keep trying to change the way the world
views software quality. And by that, I mean the way we manage defects.
Second, How Important is Software Quality?
The key question is: “Important to whom?” Developers are necessarily preoccupied with defects. They
spend the bulk of their time trying to get their products to work. And then, even when the products do
work, the developers spend even more time fixing test and user-reported problems. While few developers
recognize that their schedule and cost problems are caused by poor quality practices, an increasing number
do. This is a hopeful sign for the future.
Not surprisingly, development management tends to view quality as important only when executives do.
And the executives view quality as important only when their customers do. When customers demand
quality, executives almost always pay attention. While their actions may not always be effective from a
quality-management perspective, they will almost always respond to customer pressure. And even if their
customers do not demand improved quality, government regulation can cause both executives and development
managers to pay more attention to quality. This is true for commercial aircraft, nuclear power
plants, and medical devices. There is little question that, with commercial aircraft for example, the close
and continuous regulatory scrutiny coupled with painstaking reviews of every safety incident hold this
industry to high quality standards.
Third, Why Don’t Customers Care About Quality?
The simple answer is: “Because defective software works.” The reason it works, however, is because
software doesn’t wear out, rot, or otherwise deteriorate. Once it is fixed, it will continue to work as long
as it is used in precisely the same way. But, as software systems support an increasing percentage of the
national infrastructure, they will be used in progressively less predictable ways. When coupled with the
explosive growth of the Internet and the resulting exposure to hackers, criminals, and terrorists, the need
for reliable, dependable, and secure software systems will steadily increase. If experience is any guide, as
these systems are used to perform more critical functions, they will get more complex and less reliable.
Unfortunately, this probably means that it will take a severe, disruptive, and highly public software failure
to get people concerned about software quality.
... to read more articles, visit http://sqa.fyicenter.com/art/