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

Elisabeth Hendrickson's picture Elisabeth Hendrickson

The founder and president of Quality Tree Software, Inc., Elisabeth Hendrickson wrote her first line of code in 1980. Moments later, she found her first bug. Since then Elisabeth has held positions as a tester, developer, manager, and quality engineering director in companies ranging from small startups to multi-national enterprises. A member of the agile community since 2003, Elisabeth has served on the board of directors of the Agile Alliance and is a co-organizer of the Agile Alliance Functional Testing Tools program. She now splits her time between teaching, speaking, writing, and working on agile teams with test-infected programmers who value her obsession with testing. Elisabeth blogs at and can be found on Twitter as @testobsessed.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!