What does Quality Mean?

Posted by Mark Levison on Apr 22, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Value ,

Delivering Quality ,

Agile

Tags

Quality

What does Quality mean in Software Development? As it's used today, Mike Bria notes: ‘Quality’ refers to the "lack of defects" instead of "presence of value", as it means in more common everyday use.

He goes on to suggest:

"Quality" should be used as a measure of functional/aesthetic utility to our consumer, and not as a measure of defects. Really, it should just be assumed that defects are generally absent. This should just be implied in what it means to be a Professional.
So: I hereby propose we as software professionals and businessmen stop using the word "quality" to mean a "measure of defects".

Mike thinks that we get people writing less fragile code if the focus is not on quality seen as less defects, but quality as fit for use by the consumer. He can think of no other product where the user would say it is good quality where all that meant is that it has few defects. Yet that is exactly what we settle for in software.

Lisa Crispin, co-author of Agile Testing: A Practical Guide for Testers and Agile Teams, commented “I have never liked measuring defects so it's hard to think about what to call it.”

Christian Vest Hansen, quoting Robert Glass, says that quality is:

…a collection of attributes: portability, reliability, efficiency, usability, testability, understandability and modifiability.

Each of these attributes may rank differently in importance for different projects, but quality can never be any one of them alone. Some projects may not care about portability at all, and a product that is only reliable and nothing else, cannot be considered a quality product.

James Bach thinks that the traditional view of quality is a myth that’s not inline with software development: “The quality of a product is built into it by its development team. They create quality by following disciplined engineering practices to engineer the source code so that it will fulfill the requirements of the user.” Instead he proposes a new myth:

A product is a dynamic arrangement, like a garden that is subject to the elements. A high quality product takes skillful tending and weeding over time. Just like real gardeners, we are not all powerful or all knowing as we grow our crop. We review the conditions and the status of our product as we go. We try to anticipate problems, and we react to solve the problems that occur. We try to understand what our art can and cannot do, and we manage the expectations of our customers accordingly. We know that our product is always subject to decay, and that the tastes of our customers vary. We also know that even the most perfect crop can be spoiled later by a bad chef. Quality, to a significant degree, is out of our hands.

After many years of seeing things work and fail (or work and THEN fail), I think of quality as ephemeral. It may be good enough, at times. It may be better than good enough. But it fades; it always fades, like something natural.

Finally, JB Rainsberger suggests: “When we stop chasing objectively measurable quality, we come back to trying to satisfy specific people, I posit that helps us deliver more appropriate, more profitable software.”

It would appear that there is no clear agreement on what quality means. Instead there is agreement that quality isn’t a measure of defects. The authors agree that we need to call a spade a spade, so we should acknowledge defects as deficiencies.

1. Back to top

   Incorrect assumption

   by Jim Leonardo

   "He can think of no other product where the user would say it is good quality where all that meant is that it has few defects. Yet that is exactly what we settle for in software."
   
   That's an incorrect assumption. I can think of quite a few products where people routinely settle for a "few defects". Construction and the auto industry immediately leap to mind. I've worked in construction while working through school and rarely saw a building complete without things still needing to get done or something damaged, etc. I've rarely bought a new car and not had something that either seriously impacted the usability of the car or plain had something wrong that needed to be addressed. I could probably go on more and more, but I'd just be wasting time.
   
   My reason for pointing this out is that we can beat ourselves up trying to find flaws in ourselves and fail to miss that other industries DO run into the same kinds of issues, and DO have ways to address these that we may be able to learn from, or make sure we don't repeat the same mistakes.
   
   I'd also encourage everyone to just stop and ask the question "what is a defect?" Making sure everyone is on the same page to begin with is very helpful in these discussions. A rarely encountered, hard to reproduce, easy to understand and workaround error message may be labeled a defect while some hideously inefficient work flow isn't because the first case is measurable whereas the second isn't. When the requirement isn't met, it's easy to call it a defect. When the requirement itself is wrong, it's much harder for a variety of reasons. From the end user's perspective, it still stinks either way.

   Reply

2. Back to top

   Just for completeness

   by Mike Bria

   BTW, the part of my article not included above that some might also find worth a ponder (if for no other reason than amusement):
   

   I hereby propose we as software professionals and businessmen stop using the word "quality" to mean a "measure of defects".
   
   Well then, what word will we use? I polled Twitterverse with this question and received lots of great responses, but the group's choice as winner, courtesy of one Brian "Big Ball Of Mud" Foote, is this:
   Shittiness.
   
   Software with minimal defects has a "low degree of shittiness"; lots of defects means it has a "high degree of shittiness".
   

   Reply

3. Back to top

   Re: Incorrect assumption

   by Mike Bria

   Hi Jim,
   
   So, I don't disagree with your observation of the construction and auto industry - some existence of defects is unavoidable and generally acceptable. I also agree we might be able to learn something from those industries (and in many cases already have).
   
   As for defining "software defect", I think it's when the system does not do what the story (or requirement) intended.
   
   Cheers,
   MB

   Reply

4. Back to top

   quality of functional behavior vs. maintainability of source code

   by Michael James

   (Funny, the same topic came up today on ScrumDevelopment. I wrote this in a different discussion:)
   
   The word "quality" means different things to the customer who will use the product, the UI designer, or to the people who work directly with the code. A customer may perceive a pretty product as high quality when actually it's deep in technical debt and no one wants to touch the code. I worked with people building video games: the business perception of quality had more to do with what developers would call "scope" (highly detailed characters, accurate physical movement, etc.) Maybe using the word "maintainability" would be more clear when we're talking about avoiding technical debt?
   
   .
   . Michael James | danube.com | linkedin.com/in/michaeljamesseattle | +1.206.769.JAVA
   . 5-page illustrated summary of Scrum: tinyurl.com/dkyqjs
   . An example checklist for serious ScrumMasters: tinyurl.com/cvdwor
   .

   Reply

5. Back to top

   What is Quality?

   by Assaf Stone

   Having read "Zen, and the Art of Motorcycle Maintanence", I'm still not entirely certain I can define it. With regards to software, I know I can call it (quality) when I see it.
   
   Software that works as I expected it too, is to me the mark of quality (barring cynical views, expecting the software to fail).

   Reply

• Older >