These days, the word "Quality" is thrown around so much it's starting to lose its meaning. In this column, Elisabeth Hendrickson explains why she thinks organizations need to focus more on building good software and less on buzzwords.
I hate the word Quality. There, I finally said it. And that probably sounds pretty strange coming from someone whose company is named "Quality Tree Software, Inc."
Those seven little letters sound so good. Who doesn't want Quality? A quick search on Google™ reveals that the word "quality" appears in more pages than the basic elements of human existence: food, water, and air (105 million vs. 85, 98, and 93 million respectively as of this writing). But what does Quality actually MEAN?
Oh, we have plenty of definitions. Robert Glass did a fine job of discussing various definitions in two columns here on StickyMinds.com, one that rightly called quality a fuzzy term and another that revisited that definition (and generated a good number of reader comments). I can live with the fact that quality is a fuzzy term, in fact, the definition of quality I prefer is decidedly fuzzy. Gerald Weinberg says, "Quality is value to some person." This deceptively simple phrase contains deep implications:
- Quality cannot exist independently of human assessment.
- Quality encompasses both cost and benefit. (Most people consider something to be of value if the benefits exceed the costs—both of which may or may not be measured in dollars.)
- The person may be any stakeholder, not just the final customer.
So my problem with the word Quality is not in its inherent haziness but in the way it's used. Let's consider this conversation between two project members:
- Alice: "I don't think we should fix that bug for this release. It's a risky fix, and it has an easy workaround. Let's fix that for the next release."
- Bob: "Don't you care about Quality?!?"
What's happening here? Bob is invoking the Quality-as-a-capital-Q word instead of specifying his concerns. In doing so, he appeals to Alice's sense of duty to ship a quality product. Whether he knows it or not, Bob is attempting to manipulate Alice. Alice has demonstrated that she cares about quality by making a risk assessment, yet Bob's argument hinges on the idea that regardless of the cost or risk to fix the bug, leaving the bug unfixed indicates a lack of concern for quality. Bob is not discussing quality in the sense of "value to some person," he's using it as a rhetorical lever to win his argument.
Let's consider another discussion:
- Carl: "Our customers desperately need this capability. At this point, anything would be better than nothing. If we don't have time in the schedule to provide a full solution, we'll have to implement a partial solution and provide the rest of the functionality in the next release."
- Donna: "But a partial solution would be bad engineering! Don't you care about Quality?!?"
Carl does care about quality—from the customer's perspective. Donna is looking at quality from an internal engineering perspective. Both views are equally valid, but by invoking the Q word, Donna makes the discussion about a nebulous concept instead of focusing on specific issues.
What Donna really means is, "That's an irresponsible and boneheaded decision that will come back to bite us." But she doesn't feel she can say that (it wouldn't be polite), so she obscures her true feelings by couching her concerns in terms that are more politically correct. But, by wrapping her message in the concept of Quality, Donna is making it difficult for the two of them to work through their actual concerns and find the right balance point between internal and external quality issues.
How about this one:
- Eric: "From now on, Quality is our top priority."
Huh? What, in particular, does Eric expect will change? This is a lip-service invocation of the Q word. Eric may not even know what needs to change, but he knows that his management isn't happy with something called Quality, so it better become the number one focus of his team.
Rhetoric about Quality cannot address the underlying issues in any organization. The organizations I've seen succeed don't argue about Quality-with-a-capital-Q. They focus on underlying aspects of quality: reliability, scalability, maintainability, etc. They identify the key criteria for their environment and work toward improving their software in those areas.
Quality is fine as an umbrella term, but only if the stakeholders have a mutual understanding of the various characteristics that contribute to a "quality" product for their particular business.
Further Reading
Quality: What a Fuzzy Term by Robert L. Glass
Revisiting the Definition of Software Quality by Robert L. Glass
