The Quality Debate

Quality is a very subjective thing and often times difficult to define exactly. A quality product for one person may not meet the needs for another. This ambiguous definition along with the need to produce a product in a timely manner means that quality sometimes suffers. Everyone wants to produce a quality product but unfortunately sometimes we settle for good enough.

Quality is one of those topics which invoke passionate responses from people. For example: back in January Jeff Atwood and Joel Spolsky talked about quality during the Stack Overflow Podcast. Jeff said “quality really doesn’t matter that much” which generated some comments from Uncle Bob. Which in turn generated a post from Joel. Here is the offending statement in context.

And I find, sadly, to be completely honest with everybody listening, quality really doesn't matter that much, in the big scheme of things... There was this quote from Frank Zappa: "Nobody gives a crap if we're great musicians." And it really is true. The people that appreciate Frank Zappa's music aren't going, "that guitar was really off." They're hearing the whole song; they're hearing the music, they're not really worried whether your code has the correct object interfaces, or if it's developed in a pure way, or written in Ruby or PHP... they don't really care about that stuff.

In this context I have to agree with Jeff, just like Joel did. Software development is a very complex process that is typically driven by business and marketing needs. Meeting deadlines and producing features can become the most important aspect of building software. Whether or not the code was developed using Agile principals, Extreme Programming or Pair Programming usually doesn’t matter that much to the business. What matters is that a working product is delivered. Therefore the quality of the code isn’t as important as the quality of the product that ships, which I believe is what Jeff and Joel were getting at.

Uncle Bob’s post argues that quality is important at all levels. It is difficult to argue this point since enforcing quality at all levels will produce a high quality product. I would agree with Uncle Bob’s points that there are tools which help such as Test Driven Development which can certainly improve the overall quality of the product. Additionally following the SOLID Principals of Object Oriented Design improve overall quality and are worth the effort to implement. So I have to agree with Uncle Bob as well “quality does matter”.

I think the crux of the matter is how we define quality. Jason Young, author of YTechie, wrote a good post about quality as well. I think he sums up quality nicely:

First of all, we need to understand that quality isn’t a Boolean. It’s not “yes”, you have quality, or “no”, you don’t have quality. Quality is a gradient, but it’s even worse than that. Everyone sees it differently, and everyone experiences a different aspect of it. In short, quality is a multidimensional gradient!

I think Robert Glass provides a way to measure this gradient in Facts and Fallacies of Software Engineering. This definition of quality comes from Fact 46 - Quality is a collection of attributes.

Quality in the software field is about a collection of seven attributes that a quality software product should have: portability, reliability, efficiency, usability (human engineering), testability, understandability, and modifiability. Various software people provide somewhat different sets of names for those attributes but this list is pretty generally accepted and has been for almost 30-something years.

These two definitions are what make a product manager’s live very difficult. The product manager needs to identify the quality gradient that the potential customers are looking for. When developing a personal finance application things like usability, understandability and efficiency may be the most important. So this product may fit into Jeff’s point of view where testability and modifiability are a lower priority for this product. However, a development tool such as a database server has a very different audience. The testability, portability and reliability are probably the most important factors. This means that much more attention needs to be paid to testing and quality of code to provide the most efficient and reliable product possible.

So what do I think? I believe quality matters at all levels and that you should pick the tools, principals and methods which produce the highest quality product for your market. This varies with the product your producing and I think using Robert Glass’ quality attributes provides a good mechanism for creating a quality product. I do realize that some quality sacrifices are made because of time constraints or long feature requirements. However, these can be minor sacrifices and can always be improved upon since software is a living product.