It all goes back to how you define quality. If you look at the requirements and can you say “Does it do exactly what it’s supposed to do? As expected, under all conditions? ” Then hell yeah we can achieve 100% quality.
That would be defining quality against requirements documents, which means defining quality against the quality of requirements documents. Their accuracy, completeness, suitability, and how well they map against what’s just been introduced to me as Quality Moving Targets. As we can’t have requirements documents with 100% completeness, in theory or practice, then we’re saying that 100% quality is only applicable to stuff we thought of that’s convenient. Maybe that’s fine, I don’t know, but it seems limiting.
“Exactly what it’s supposed to do” - I guess according to whom? What is it actually supposed to do? Does anyone want it to do that? When, how, why, how often should it do that? What if it can’t do that? All vital quality factors you see every day. If two people differ on exactly what it’s supposed to do, or more accurately what and how they’d like, then who wins?
Also, all conditions? Ignoring the pedantry of “what about during a zombie apocalypse?!” type questions, knowing that we cannot possibly replicate all conditions, or even think of all of them, how do we know which conditions are required to fulfil our quality percentage? If we place that onus on the requirements documents, then we’re just shifting that question to whoever wrote the requirements documents.
I think we can invent ourselves occasions where “100% quality” as a floating term without meaning or purpose makes sense, such as defining it as the sun rising in the morning, but I don’t know how useful that is when making software for money. We can say 100% quality is “something we decided” doing something we decided under expectations we decided under conditions we decided, but then we’re abandoning the idea of value to a human person and replacing it with code maths and favourable contracts. How useful is it to say we achieved 100% quality when our clients hate our product?
But I believe quality is only something like a moment in time. Like “right now” we could have no known defects and it’s all stable, but that doesn’t mean that over a year it will be the same, with all the framework updates, new vulnerabilities, new browsers etc…
So “for now” we can for sure achieve 100% quality.
I think this time factor is an excellent point and an example of how dynamic elements shift under a quality definition. I think if we look at that year as a time when changes happen we can probably guess there will be one point at which something’s different. So if something can change over a year, it can change in a day or a second. Given enough factors to know about such that it takes longer than a day to know them, then “right now” is more of a ideal than an achievable goal.
Also it’s not just about technical changes but business and social ones. If someone changes their mind about what a good product is. If a competitor launches a similar product. If there’s a downturn in the economy. It’s also about how your product is placed in the market and what your userbase looks like.
So yeah, it’s achievable if we say it is, I just can’t see how and when that’s useful in practice, I guess.
. Its all about the perspective you approach it as to how you answer.
on it!