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