The Illusion Of One Dimensional Quality
I read a lot of articles and blog postings about software development, management and quality. My “favorite” articles are characterized by their ability to present some idea or concept with a sound voice, while blurring other important aspects of the subject. Most of them are not doing that on purpose. But the innocent reader might still get a wrong (or incomplete) picture.
The problem is that while you read such articles you are nodding your head with agreement and understanding. You don’t perceive them as wrong. Well, often they are not really wrong, but they might create the wrong impression.
The latest article posted at the Tyner Blain site is one such article. Its title sounds promising, the diagrams make sense, and the content… sounds accurate. It’s hard not to agree with the text on first reading. But what kind of impression does a project manager or a development team leader get from it?
The first two lines are enough to send a clear message to the reader:
“What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work?”
These two lines create a certain mindset – an implicit message the reader takes with him: software quality means how well the software works. The rest of the article explains that this is the customer’s view, but these first couple of sentences didn’t mention “the customer”. They referred to stakeholders.
Software quality has much to it than just functional quality. There are many stakeholders in every project. The customer is not the only one with interest in the product.
Your company, for example, also has a clear interest in the product: for the product to have value in the future it will have to evolve. The quality of the product’s code and design has an immense effect on future development costs, and therefore on the value of the product to your company. Arguing that stakeholders care only about functionality, might just convince the reader that the internal quality of the product is of no importance.
But even from the customer’s perspective there is more to quality than just a working product. Although the customer usually don’t care about the design and implementation details, he does expect a reasonable quality of service after the product is delivered. The customer expects a prompt service when a fix is needed. He expects the product to be stable when a new feature is added in a later release. You cannot meet these expectations without ensuring the internal quality of the product.
You can think of it as if the customer has a set of implicit requirements regarding the future of the product and the service he receives. He might not communicate these requirements explicitly, but that does not mean that he will be willing to accept an unreasonable service.
Now, I don’t really believe the author of the article was trying to say that code and design quality are not important. But since these aspects are not even mentioned in the article, the message is that functional quality is the only thing to care about. It is not.
Quality is not one-dimensional. Not every dimension is of interest to every stakeholder, but most of the time the different aspects of quality affect each other, so they can’t really be treated in isolation.
April 29th, 2006 at 8:17 am
This is definitely the most eloquent critique of anything I’ve written. Thanks very much.
I used customer and stakeholder interchangeably in that post - probably not a good idea. What I was trying to capture was the idea of “everyone not on the team, who cares about the output of the team.” I think of all of those people as customers, not just the people who give us money.
I completely agree that maintaining internal quality is critical to success. My point was that while it is important to the people on the team, the only thing that is important to people not on the team is the result of that high internal quality.
The analogy of a plant manager for a manufacturing site holds pretty well, I think. That plant manager tells his customers about the defect rate in shipped products - that’s how quality is shared. Inside the building, that plant manager reviews control charts, six sigma reports, sampling data and status reports from every element of the manufacturing system. By monitoring those controls, he can make sure that he delivers a low shipped-product-defect-rate. The plant manager isn’t going to tell the customer that the spring-angle on the contact arms is running at +/- 1.8 sigma within tolerance bounds.
Granted, some customers may want to audit the quality processes - but this isn’t the common-course for communication, and should be treated as the exception to the rule that it is.
Thanks again for your great feedback, and thanks for reading. I hope you’ll stay with us, and continue to point out where we can do better!
Scott
April 29th, 2006 at 8:45 am
Hi Scott,
Thanks for responding to the article review.
I agree with your approach regarding the communication with customers. But I think there is still a need to emphasize the improtance of internal quality.
By that I am not referring solely to internal metrics (such as the one you mentioned in your comment). Internal quality deals with entirely different aspects of the product: its maintainability and extensibility as reflected in the quality of its design and code.
This is not just another metric, nor is it the quality of the process. It is part of the quality of the product, but not its functional quality. Maybe the customer does not care about these qualities (although I believe he does, implicitly). But other stakeholders should have these attributes at the top of their list…
Lidor