Posted by Ben Simo
“Quality is value to some person.”
Gerald Weinberg,
Quality Software Management – Systems Thinking
This morning, Jason Gorman's blog post title Proof That Value Has Little To Do With Quality? caught my attention. This title contradicts my definition of Quality. To me, Quality is all about value to stakeholders.
Quality is not about implementing the best development practices. Quality is not about writing solid code. Quality may not be about impressive features. Quality may have no relation to elegance. Quality may not even be reliable. Quality may be cheap or it may be expensive. Quality may be well planned or it may be haphazard.
Quality is all about value. Quality is about value to people that matter.
Jason references an interesting article about a web site that started as a learning exercise and "seems to come from the Anti-Perfectionist School of Design", yet is profiting its creator millions of dollars annually. In spite of many flaws, this web site is profitable because users find it valuable and users bring advertising dollars. I consider this to be a high quality web site in spite of its obvious flaws because it has value to people who matter. Instead of viewing this as an example of value having little to do with quality, I see this as a great example of Quality having everything to do with value. I suspect that Jason and I define Quality differently. This story is an example of how value sometimes has very little to do with all the other things we often call Quality.
Perhaps my thinking is too touchy-feely for those who think we need to measure and assure Quality through quantitative metrics and processes enforcement. By it's very nature, quality is subjective. Sometimes we can quantify the results of Quality: as in the $10 million in annual advertising profits. I suspect that some of you are subjectively estimating how better metrics and process might lead to better profits.
The real measure of Quality is a measure of value (not necessarily quantitative value) to those who matter.
"As professionals, we have no real control over the ultimate value of the software we create. And neither do our customers, or requirements analysts, or product owners, or whoever it is who's been charged with figuring out what the best use of the budget would be. It's all guesswork, like choosing lottery numbers or selecting which horse to bet on."
- Jason Gorman,
Proof That Value Has Little To Do With Quality?
Interactions, collaboration, and responding to our changing understandings can help us take control over Quality.
"Above all, listen to what your customers are telling you about Quality. ... Your customers are in a perfect position to tell you about Quality, because that's all they're really buying. They're not buying a product. They're buying your assurances that their expectations for that product will be met. ... Your customers may not have all the hard business facts. They may not be aware of your specs and your standards and your inspection reports ... They may not be able to give you a precise definition of Quality, but one thing's for certain -- they know it when they see it."
-John Guaspari,
I Know It When I See It: A Modern Fable About Quality
And, as Jason rightly points out, what satisfies users (and the business) today may not satisfy them tomorrow. Keep the dialog going.
3 Comments:
January 15, 2008-
Gerald M. Weinberg wrote:
-
-
January 18, 2008
-
Anonymous wrote:
-
-
March 10, 2008
-
Anonymous wrote:
-
-
I love your interpretation of the "poorly designed" website that makes millions for its owner.
Even so, there's a way to reconcile the two different views of quality, if you consider quality over time.
Since quality is value to some person, the owner's idea of quality may decline if the income declines over time.
And the income may decline over time if the site is poorly designed in a way that allows imitators to come along with better designs that steal the original owner's customers.
In that sense, "poor design" might come to equal "poor quality"--but of course the original owner still has his millions and probably doesn't care that much if the site is now of "poor quality."
IOW, "quality-over-time" may very likely change for any system, even if we're looking at the same set of people who value it. In some ways, that brings different views together, some saying "poor design might lead to poor quality at some time in the future."
I know that many feel Certification is usless but I've completed a couple and they have been helpful in making me think about what I do as a tester and why. One area discussed was concerning the "Quality Gap". We often think that Qualty is "Conformance to Requirments" from a software development point of view. A closer definition would be 'Fit for use' from the customer side. These concept were put forward by Phillip Crosby, Dr.Joseph Juran and Dr.W Edwards Deming. Deming as you may recall, was told to basically take a hike from American companies so he went to Japan in the 1950's. The rest, as they say, is history.
The lesson in all of these postings and discussions is that unless you define and frame a definition of quality, any subsequent discussion is likely to rapidly become a mindfield as people process what they hear via their own differing definitions of the word "quality".
Speaking as a Brit living in the USA, I find that many clients over here have a definition of quality that is very much based on initial cost. They are not very receptive to longer-term arguments such as architectural integrity, design quality etc.
I echo the "fit for use" comment; in my 30 years in the industry I have seen many examples of software solutions that met (and in some cases) exceeded all of their original technical objectives, but ended up being regarded as failures by the business users that paid for them. Any definition of quality assurance that does not include assurance of fitness for use is immediately deficient.
Post a Comment