In this column, Bob Glass returns to a topic that stimulated a lot of discussion on this Web site in his previous column--the definition of software quality. Here, he responds to your comments, which totaled more than double the usual number. Bob stands his ground (with some clarifications) on what quality is…and isn't.
I've been having some fun recently, looking over all the comments you readers have made on the articles I've posted to date on this Web site. And there was a big surprise among all those comments. My column on the definition of software quality ("Quality: What a Fuzzy Term") stirred up a great deal of discussion-more than twice the number of comments for any column to date.
So let's revisit that whole definition of software quality.
What Readers Said
In the twenty-seven comments so far, there are basically three themes:
1. Quality can or cannot be defined.
2. Quality can be defined, and it's______________.
3. To talk about quality, we must talk about_______________.
Let me tackle these themes one at a time.
With regard to whether or not quality can be defined, seven people flat-out said, "Quality cannot be defined." Five people said that quality CAN be defined, but I failed to do it in my article. Two people said that quality CAN be defined, but its definition must be project specific. And one person defended me, saying I did in fact define what quality was. One out of twenty-seven isn't bad! (I'll return to all of these issues below.)
Regarding choosing sides as to the definition of quality, five people said that it was about the customer. Three people said quality was about meeting requirements. One person said it was a lack of errors. (Once again, I'll return to these issues below.)
As for broadening the topic of quality, two people said quality would be meaningless unless it could be quantified. Two other people said that quality emerged from concerned and caring developers. One person said that "documentation" should be added to whatever definition of quality was to be used. And one person said that good process was the way to get good quality.
What Does It All Mean?
Now, let me take a step back from all this input. One thing seems particularly apparent. Though my article may have been provocative, it wasn't as clear as it should have been. And another thing is equally apparent. No matter how clear I am in what I say, some people are going to stick to their guns and disagree with whatever definition I provide.
With all of that in mind, let me take one more stab at what I intended to say in my column. I wanted it to say what I thought software quality was. And I wanted, perhaps even more strongly, to say what I believe it is not.
First, what do I believe quality is? (Given the number of "you never defined the term" comments, obviously I didn't do this one very well.) I believe very strongly in this nearly-40-year-old definition. Quality is a collection of "ilities":
-reliability - the ability to operate error free
-modifiability - the ability to have enhancement changes made easily
-understandability - the ability to understand the software readily, in order to change/fix it
-efficiency - the speed and compactness of the software
-usability - the ability to use the software easily
-testability - the ability to construct and execute test cases easily
-portability - the ability to move the software easily from one environment to another
(Note that in the previous column, I failed to mention "efficiency." Although it doesn't end in "ility," that was a serious omission.)
You'll probably notice the ordering I've put on these "ilities." If there were such a thing as a universal ordering, this would be my choice-reliability first (the software has to work), portability last (platform independence doesn't matter for many software systems). But there's not such a universal ordering, and there shouldn't be. For one thing, everyone's ordering priority might be very different. For another thing (and this is the most important reason of all), the ordering of the "ilities" should be project dependent. If you're building a system that is to be platform independent, then portability should leap to the top of the list. If you're building a system that you expect to keep around for a long time, then the two maintainability traits-modifiability and understandability-should move to the top of the list. If you're working on a hard real-time problem, where nanoseconds and/or memory space count a lot, then efficiency belongs at the top of your list. In fact, ordering the "ilities" at the beginning of a project is a vital, identifiable task-and one in which your customers/users must participate.
So there's my clarification about the definitions of quality. And, with this elaborated definition, I think I've covered the ground many of you suggested, such as the thought that quality should be project specific (my answer being that the elements of the definition don't change, but the ordering must).
Second, what do I believe quality is NOT? That's where I presented the following equation:
User satisfaction = Compliant Product + Good Quality + Delivery Within Budget/Schedule
No one seemed to disagree with this equation in their comments. The equation is nicely intuitive, and captures something I believe is extremely important about a lot of vital characteristics.
But notice what happens when you accept this equation. Quality stands alone, distinct from all the other entities mentioned in the equation. It's NOT the same as "user satisfaction." That's a much more complicated entity, for which good quality is only a subset. It's NOT the same as "compliant product" (meeting requirements)-that's clearly different from quality. It's NOT the same as "delivery within budget/schedule." I don't mean to diminish the importance of user satisfaction, or meeting requirements, or meeting estimation constraints. Those are all really important things. It's just that they are separable from, and rather importantly different from, quality.
And what about those of you who suggested that the topic of quality should be broadened? Here's how I feel about the suggestions readers made:
How about the thought that quality should be quantified? That's a tough one. My first answer would be "yes, of course it should." But how? If you, like me, believe that quality is a collection of "ilities," then it is those "ilities" that you must quantify. For some, it's easy-reliability and efficiency. For others, it's next to impossible-modifiability and understandability. Wishing and believing that quality should be quantified are not enough to make it so. Some elements are quantifiable, others are not.
What about those ways of enhancing quality, like "caring/concerned developers" and "good software process"? Good people and good process are both roads to good quality.
And finally, what about the role of documentation in all of this? There's no doubt in my mind that documentation is important. Especially user documentation, but also accurate and up-to-date maintenance documentation. But I think it is important that we separate software from its auxiliary features, such as documentation. Getting good documentation is important, and it is a matter of managerial will, as well as technical skill.
Normally, I hate to revisit old topics. But in this case, with all the intriguing comments readers came up with, I think it was valuable. I hope you'll agree.
