Quality: What a Fuzzy Term


reliability, even if it does cost an arm and a leg (in both time and dollars) to install. With SAP, in other words, I expect a compliant product with high quality, and I'll sacrifice some cost and schedule to get it.

Notice that in the three examples, quality is demonstrably different from user satisfaction, from meeting requirements, and from cost and schedule considerations. Any definition that equates quality with one or more of those topics has simply muddied the waters.

Now, why do I get so excited about all of this? Because quality, for all its fuzziness, is an important topic in the software field. We spent the 1980s, I would assert, trying to find ways of improving the productivity of software people. We spent the 1990s, I would also assert, trying to find ways of improving the quality of software products. That's a lot of years to spend on productivity and quality. I think we all have a kind of intuitive notion about what productivity means; I see no mass disagreement there. But quality? If we can't agree on what quality is, how do we know whether we ever achieved anything at all in its pursuit?

My personal belief is that those major thrusts of the 1980s and 1990s both failed. The thrust toward productivity failed, I think, because we were extremely naive about how easy it would be to make software people more productive. We saw panaceas in things like 4GLs, CASE tools, object-orientation ... (name your own overly hyped productivity poison), and none of them bore the fruit that their optimistic advocates promised.

And the thrust toward quality failed, I think, because of a similar naiveté. But it also failed, big time, because we in the software field never really got around to agreeing on what quality really meant.

So what's my bottom line here? Software quality, at heart, is a bunch of "ilities." Different people construct different lists of what those "ilities" are, but they all pretty much agree on the same basic notions.

Having said what quality is, it is also important to do away with erroneous notions of things that it is not. The next time you read about someone saying that quality is about lack of errors, or user satisfaction, or meeting requirements, or achieving cost and schedule targets, remember this: Quality is none of those things. But it has an important relationship with all of them.

Editor's Note: Robert Glass has written a follow-up to this column in response to the many comments: "Revisiting the Definition of Software 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.