Over the past week I was surprised to receive a pingback from Eusebiu Blindu on Quality is value to some person at some time. He raises some very conscious thoughts about the term quality, value, and the Relative Rule from Michael Bolton, so make sure to read it, as I will explain some nuances from the Quality Software Management Series from Jerry Weinberg that should explain the pieces I left out so far.
While I read Sebi’s reaction, I noticed that he didn’t know about Weinberg’s definition of value in his famous quote
Quality is value to some person.
He defines value as
What are people willing to pay (or do) to have their requirements met?
(Quality Software Management Volume 1 – Systems Thinking, page 7)
Once you start to think about it, there is more to it. What do I need to pay? Obviously, I might be paying monetary funds to have my requirement met, or I might want to pay in other non-tangible funds such as trust or time. In fact, the whole concept behind refactoring and the metaphor of Technical Debt makes use of this, though it’s not a debt solely, but I may want to pay for the technical inconveniences that were introduced into the application before.
Next to the payment, the doing is relevant in the above sentence, too. What are people willing to do in order to have their requirements met? Are they willing to participate into the project? Are they all time available to answer questions about the written manifestation of their requirement? The Agile world refers to this as the inclusion of the customer, or at least an easy access to expert users (see Cockburn).
In addition, the Time Trigger raises the question about the point in time when the person with the statement about quality is willing to pay (or do) something to have his or her requirements met. This might be today, or maybe next week.
But, how does all of this help at all? So far the statement alone does not help to come up with a meaningful thought about quality, now does it? Well, not quite. Far too often I hear statements like “We need better quality.” or “Please deliver the product on time and in the necessary quality.” Among them, my most favorite is “We got a quality problem.” Since every problem in the software is a quality problem, this statement is always true. Think about it. The problem of course comes from the quality fallacy. If every problem with the software, is a quality problem, we should rather start to get to know to whom this is a problem, instead of fixing it right away. Then we can make the careful thought whether or not we should bother, and act upon it. So, this explains that instead of a general “we have quality problems” we should productively think about “whose quality could be hampered?” first.
The next step then is to consider the person behind the quality statement. Do I care about him? Does my project’s stakeholder care? Does my company care? Does my wife care, if I lose my job? The problem with relative and personal quality statements comes from the problem, that improved quality for one person may mean reduced quality for another person. Just give your wife your purse, and you can see this come into effect. She buys more quality (for her), and gives you back less quality (for you) when your purse (or credit card) is empty. And it’s the same among software projects as well. More traceability for the support crew in terms of logging may mean less performance for the end user. More features for the expert user may mean less usability for a new user of your product.
At this point of our quality consideration, we need to make a trade-off decision. About whose quality do we care more? And is the one we care more about paying us to have his or her requirement met? Last, when is he (or she) going to pay? These are management decisions to be made. And all of this explains why Weinberg picked the name Quality Software Management for the title of his book series. And I wholeheartedly recommend reading them. I noticed that just few copies of it seem to be left, so maybe make sure to grasp one now.
Back to how all of this might help. The next time a statement about quality is made, the first thing that pops into my mind is, “whose quality? When?” By answering this question mentally I am unlikely to understand what the one with the quality statement said, so I will ask “excuse, but I have troubles understanding whose quality we are talking here about? Can you please have a discussion on this, so that we gain a shared understanding.” And this is finally where the productive part of the quality discussion may start…
Thanks for mentioning my post. Yes it’s true I am not familiar with some books of reference, including the one you mentioned. But I am trying to read and get informed.
Well, a value of a quote is to be understood in time, through practice and experience and always gets “upgraded” with different sides to it.
I like the examples and how you try to explain the value, as I see it it is resumed simply to the context and the ability to study the context.
–Sebi
Hi Markus,
Interesting post. Now I’m going to be the layman’s devil’s advocate….
Suppose the stakeholder doesn’t use the word quality in their product specification or requirements.
The stakeholder’s values are related to his budget, timescale and his set of requirements.
Do we need the word “quality”?
Does the word “quality” need to be introduced? If so, to what purpose? Do we need a single word or should be just talk about the stakeholder’s values and/or requirements or something else (some other word/categorisation)?
No, introducing some term just for the sake of having introduced it is clearly not of any value. But I recommend to have the conversation on what the stakeholder values in first place. Whether or not you call this a discussion about quality, I leave to you. :)