Redefining Quality


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, 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?!?"

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.