6 November 2013
Quality. What does it even mean?
by Peter Kananen
I’ve recently started reading an intriguing book called Quality Software Management. This isn’t the latest book on Agile methodologies. Instead, this is a book you’ll have to buy used, as it was published in 1992. The author, Gerald Weinberg, admits the title is somewhat ambiguous. Is this a book about the management of quality software? Or is it a book about the quality of software management? It turns out it’s actually both. It turns out that quality is an extremely subjective word in general, and especially so in the world of building software.
If asked to describe quality, many people might resort to the Justice Stewart position and state “I know it when I see it”. This is essentially a way of saying that judgment is always subjective and relative to the people involved. Weinberg reminds us this is true when he says that “quality does not exist in a nonhuman vacuum”. So, when we talk about quality, we are also making a related statement about some person(s). At this point, you might believe that “conformance to requirements” is all that really needs to be said about quality. However, consider the quality statements outlined in the book, shown below. (note: some of the language may need to be adjusted for modern technical environments)
Zero defects is high quality
- to users whose work is disturbed by those defects
- to managers who are criticized for those defects
Having lots of features is high quality
- to users whose work can profit from those features
- to marketers who believe that features sell products
Elegant coding is high quality
- to developers who place a high value on the opinions of their peers
- to professors of computer science who enjoy elegance
High Performance is high quality
- to users whose work taxes the capacity of their machines
- to salespeople who have to submit their products to benchmarks
Low development cost is high quality
- to customers who wish to buy thousands of copies of the software
- to project managers who are on tight budgets
Rapid development is high quality
- to users whose work is waiting for the software
- to marketers who want to colonize a market before the competitors can get in
User friendliness is high quality
- to users who spend eight hours a day in front of a screen using the software
- to users who can’t remember interface details from one use to the next
These statements about quality can be at odds to one another. Adding another feature may take longer and may take more money to build, and may result in a less elegant codebase. However, this added feature may be the one that makes the software valuable to a large group of people. In other words, quality for one person may result in less quality for another. This is likely the point at which companies perform cost/benefit analyses to optimize for “total quality”. This is when building software gets really hard. Chances are good that some of these dynamics also occur at your company, or on your project team. Have you struggled with understanding what quality really is? How do you make decisions about optimizing quality for all involved parties?
