3/27/2009

Killing "Quality"

So, a guy walks into a bar...

No, just kidding. But seriously though...

You walk into a bar and order a "low quality" beer (tough economy these days). What does this mean to you? That it'll come out with a bug swimming in it? That it will be served heated up? That it will be skunked? Glass only half full?

No, of course not. You'd be appalled, outraged. Have every right to ask for your money back. This place has acted in bad faith, they've acted unacceptably. You leave angered and vow to never return.

Your wife wants you to drop $600 on a new Louis Vuitton bag (you gotta buy cheap beer and she' still asking for Louis?!?), because it's a "top quality" product. Does she describe it this way because she knows it has less likelihood of falling apart the minute she gets it, or its colors smearing, or it having holes in the bottom? Again, no. These things are assumed to be absent. In the rare case you do happen to find anything like this, you are sure to invoke "return to sender, no questions asked".

I could continue on this way throughout various types of products, but I suppose you get the point.

Well, this ain't the case with our industry (Software Development). So I ask ye: WTF, man?

We use the word "quality" as an indicator of both "value" and/or "defect" presence, interchangeably.

When someone says "high quality" they could very well be talking about the absence of defects or they could be talking about the presence of value. And by software standards, neither would be an inappropriate use of the word.

Not so in the bar, not with your beer. Why then for us? Again I ask, WTF?

I know, I know. Some of you are sitting there saying (correctly), "hey, wait, agile pays attention to customer feedback to iterate towards a higher quality solution. We're talking about 'value presence' there." Or maybe your saying, "Our company's website says 'highest quality product in the industry!'. That's talking about 'value presence' too! That's what we mean when we say 'quality'."

Well, maybe so (and good for you, seriously). But I bet many of you still call your testers "the QA folk". "QA", as in Quality Assurance, as in "Those who ensure quality". But really, is their (primary) function that of ensuring 'value presence', or of ensuring 'defect absence'? Look, don't get me wrong, on a healthy agile team these wicked cool cats ARE involved in 'ensuring high value', but at the end of the day that isn't why you're calling them "QA'ers".

I've seen my share of "quality review" meetings, or fancy charts of "quality metrics", or annual budgets that talk of "quality goals" ... where in each of these cases, "quality" is talking about DEFECTS.

When was the last time someone described the benefits of TDD without mentioning, excitedly, "increased quality"? (And, yes indeed, I am certainly just as guilty as the next guy.)

So, why do I care? Why the rant?

Because, it's an indication of the generally absurdly high level of tolerance our industry has for defects.

That we describe defect density with the same word that we use to describe product "value" (to our customer/consumer) is gross.

Heck, I'd go as far as to say its a part of the reason that we have such a generally high tolerance in the first place. It's confusing and it is misleading. It's too easy to masquerade our defect problems as a "quality improvement initiative" or some other politically wimpy label.

When our customers get a bunch of "bugs in their beer" why aren't they appalled and outraged? Why aren't we? Why don't they storm out and vow to never come back? Why is it so damn okay to have defective software? For the third time, WTF?

Don't get me wrong, I'm not saying we should have an absolute "zero defect, period" attitude, that's simply unrealistic considering what we do. But we should have a low enough tolerance for defects that it makes no sense for us to use the word "quality" when talking about them.

"Quality" should be used as a measure of functional/aesthetic utility to our consumer, and not as a measure of defects. Really, it should just be assumed that defects are generally absent. This should just be implied in what it means to be a Professional.

So:

I hereby propose we as software professionals and businessmen stop using the word "quality" to mean a "measure of defects".

Well then, what word will we use? I polled Twitterverse with this question and received lots of great responses, but the group's choice as winner, courtesy of one Brian "Big Ball Of Mud" Foote, is this:Shittiness.

Software with minimal defects has a "low degree of shittiness"; lots of defects means it has a "high degree of shittiness".

Of all the tweep responses though, overall my very favorite was from Lisa Crispin who said, "I have never liked measuring defects so it's hard to think about what to call it."

Nice, now that actually says it all. Something tells me that Lisa's company does not simply think of their testers as "the QA folk". There is hope!

I think I get your points, but I've had to think way too long about the semantics game to get here. Value is a different discussion than quality, I'm not sure you should mix them up. Value is a quality, but a quality is not necessarily a value. (I just studied dictionary.com pretty hard to make sure my confusion from this post was justified.)

Either way, I agree that neither quality or value is a good word to describe the absence of defects since all software should be absent of defects.

I don't agree if you are implying that it is on a development (including QA) team to insure value in a product. That is a shared responsibility that the team plays part in, but most of this ownership goes to the business, product owner, customer.

I think it's time to go to lunch again, because this is a debate I'd like to talk through.

I'm not sure you got my point. It's less esoteric than what you've said. Basically, the very primary point is this: Our industry takes "defective product" WAY too lightly.

My slightly more underlying point is that treating "defectiveness" as measurable/meaningful aspect of "quality" is a great dysfunction of most of the industry.

A more healthy view is to consider product "quality" as a measurement of how functionally useful (and thus "valuable") your product is to its consumer. If the product's feature set is highly useful, it's "high quality"; if not, "low quality".

Bottom line, its less about the semantics game, and more a message of "get your act together" - if your primary focus in managing "quality" revolves around managing "defects", then you've missed the boat (sadly, along with a large majority of the industry).

As for "ensuring value ...is a shared responsibility", I absolutely agree. Not sure how you got that confusion from what I wrote.

About MB

I dig bringing great things into the world, and sharing with other people. I've been doing various forms of bad-ass software for years, and these days I work for Industrial Logic as an XP coach/trainer, as well as write weekly for InfoQ. Frankly, I love doing this stuff, and love helping others love it too.
Twitter @ mbria