> Jerry's Weinberg's line is "Quality is value to some person."
To everyone but me, that line is an Aha! moment, but I've never gotten
it. What does it mean? If quality is value to some person, what is
value? Quickbooks has no value to me: what does that say about its
> Quickbooks has no value to me: what does that say about its
Hm. Maybe not much. "value to some person". SOME person, but not ALL
Of course, from Quickbook's POV, the more persons the better.
All that said then...
I think Weinberg's line summarizes my "Killing Quality" article. My
point is that we should be thinking of our consumers (aka "some
person(s)") as *valuing* the functional usefulness they get from our
products and viewing "low defectiveness" to be something they can
> Because quality is so ephemeral and relative, it's very important that
> we get into the heads of our stakeholders and figure what matters to
> them. (The Michael Bolton extension to this quote is "Quality is value
> to SOME PERSON THAT MATTERS.")
> Does that help at all?
Yes. I'd say "quality is subjective" but Bret Pettichord pointed out
on twitter that omitting "subjective" (a bad word) and adding
"value" (a good word) is, um, the viral capsule that allows the
payload to evade the body's immune system. [My metaphor, not his.]
> Seems to me the definition leads to the conclusion that, *to you*,
> QuickBooks has low quality. And that's a valid conclusion.
To me, QuickBooks has low value. It seems bizarre to say that,
therefore, to me it has low quality. How, then, could I say that it's
a bug-ridden pile of dung with a user interface to match - but it's
nevertheless worth what I paid for it?
I know! I could just *say that* instead of filling in the blank in
"quality is ______". But man is a featherless biped with broad
fingernails who insists on defining things.
[Allusion to: http://www.conservative-resources.com/]
My current rant (I have been talking with a few "QA Engineers" i.e.
testers lately, that seem to think that quality is all about passing
acceptance tests with no immediately visible defects) is that quality is
not about testing or merely meeting requirements.
It really is about all those other aspects listed in ISO 9126 and
mentioned by Robert Glass.
I think more communication with the customer, or more focus on what the
customer wants is a bit of a read herring. All they want is a big ball
of mud that passes its acceptance tests with no immediately visible
defects. I guess six months later they also want that tricky sporadic
bug fixed, or that small feature implemented, but right now they don't
understand why the tight coupling between the gui and db make that
We need real QA engineers or managers (testers do QC at best). Payers
back of technical debt, separators of concern, upholders of Demeter's
law, not failed coders who can click a "Test" button and determine that
all the green lights indicate quality in some way.
Oh and regarding portability, it is important. Not just porting to other
operating systems, which is what most people think, but for example,
porting the persistence concern to a new version of the dbms, or a new
dbms entirely, while leaving the software itself unchanged, or updating
the gui with a new look while keeping the core business logic unchanged.
Even if this isn't planned for, quality software makes it at least
BUT..I'm with Brett on this one (as if that's not already obvious).
I think that allowing "Quality" to be this wishy-washy umbrella word
has led our industry into a funk that doesn't pay enough serious
attention to what it means by "quality". Further, that it has led us
to lose all real meaning for what it should mean.
I'm hoping we can get more attention to not saying "quality", but
rather say things that actually put spotlights on what we're actually
talking about (be it "value", "defectiveness", "reliability",
[X]-"ility", or whatever).
On Mar 30, 2009, at 6:08 PM, John Goodsen wrote:
> "Quality is in the eyes of the beholder" is the mantra I chant.
The "aha!" moment comes from realizing that there is no single
objective quantifiable measure of quality, but rather, as Wikipedia
puts it --
This definition stresses that quality is inherently subjective -
different people will experience the quality of the same software
very differently. One strength of this definition is the questions it
invites software teams to consider, such as "Who are the people
we want to value our software?" and "What will be valuable to them?"
When we stop chasing objectively measurable quality, we come back to
trying to satisfy specific people, I posit that helps us deliver more
appropriate, more profitable software.
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Diaspar Software Services :: http://www.diasparsoftware.com
Author, JUnit Recipes
2005 Gordon Pask Award for contribution to Agile practice
Register for Agile 2009 at http://www.agileregistration.org
If it's worth what you paid for it, then how is it low value?
So, what I'd like us to focus on recognizing from this (particularly
what JB says below) is that "quality" is subjective to the people
using the software (agreed, all good with that), BUT that you'll
notice this subjectiveness revolves around "value".
That is he point of my post.
Defectiveness (bugs, etc) is what I see everywhere I go as the #1
thing people are referring to when "quality" hits leads the
That's wacked. We've let ourselves cover our
irresponsible-development habits/results (broken software, bugs, bad
craftsmanship) under a label which is allowably subjective, and
intended to be focused on value.
I think this is a root of dysfunction in the majority of our business,
and one we'd do well to dissuade if we would like to see the ideas of
My rants @ http://aydsoftware.blogspot.com/
My co.'s fantabulous XP eLearning @ http://industriallogic.com/elearning/