Quality Is Not Free

A contrary view to QualityIsFree. The suggestion that quality is "free" seems to come from the observation that doing the right thing up front will cost x, whereas doing a shoddy job up front and having to pay for it later (through increased expenses for rework, business lost due to pissed-off customers, etc) will cost x+n for some n>0. Since you have to pay the x regardless; it is therefore "free".

In reality, doing anything will cost x. If you wish to maintain that thing (as most businesses do), you must pay extra no matter what. The cost of retroactive maintenance (as mentioned above) is x+n, while the cost of ensuring quality (and therefore cheaper maintainability) is more like x+q, where 0<q<n. Quality is always cheaper, but never free.

Quality is indeed, in the long run, less expensive than the lack thereof. But it is not "free". Unless one has engineers that produce perfect designs and write flawless code (to say nothing of requirements specification and manufacturing processes), extra work (i.e. testing, in all its forms) will be required to drive the bugs out of whatever system it is you are trying to develop. Since I have yet to meet a perfect engineer, it follows that testing (and all of the labor and capital expense involved) will be required.

I think we are all agreed that this is the right thing to do.

The problem with QualityIsFree is that despite the conviction we all have (and the considerable evidence to support that conviction) that QualityIsCheaperInTheLongRun? ; GettingItRight requires investment up-front. Depending on your processes, policies, and procedures, somebody has to validate customer requirements. Somebody has to write the unit tests (ideally, a cheap process, but still it takes time). Somebody has to execute stress tests and other whole-system tests (unit tests on modules are necessary but not sufficient in my experience). Somebody has to design, purchase, and assemble a test system in manufacturing, for those of us working on projects which involve ActualHardware?.

And the problem with this is that it costs real time and money, up front. Too many BeanCounters and PointyHairedBosses, whether constrained by budget limitations or just hoping to get something for nothing, aren't always willing to spend that money up front. (An old chestnut which they often invoke is "a bird in the hand is worth two in the bush"; in other words, it's better to save money up front even if it costs more in the long run. Because then it might be SomebodyElsesProblem). See also NetPresentValue.

So what happens? Either the design team conceals the testing activities in the schedule, keeping them from the view of management (IfTheyCannotSeeItThenTheyCannotCutIt?); or else testing activities go by the wayside, resulting in less-efficient manufacturing processes, pissed-off customers, and maintenance headaches. (As an aside, one advantage, I suppose, of ExtremeProgramming is that the testing load is distributed among development, rather than as a visible BigBang at the end; thus a less tempting target for managers looking for "overhead" to cut. Unfortunately, too many managers do take the view that testing is overhead. I've met several engineering managers who themselves value testing, but have learned not to taint any engineers with the label "QA" because guess who gets laid off first? See QualityIsOverhead?.)

The problem for us as engineers in such an environment, however, is obvious. When management eventually becomes aware that the product they are shipping has some rather obnoxious defects in it, is expensive to manufacture, and difficult to fix - and the engineering team is invariably asked the question: Why didn't you write better code?

And this is the problem with the notion that QualityIsFree; it produces the expectation that high-quality code (or any product, including those involving no software whatsoever) should come naturally with no effort; and since n times free is still free no matter how large n is, this is extrapolated to the belief that perfection should also be free. The conclusion to this line of reasoning is that any defects in a product, no matter the constraints the product was developed under, are therefore entirely the fault of the designers; the management who was unwilling to budget for proper testing activities is blameless. Because, after all, QualityIsFree, engineers should AutoMagically design it in as part of their day-to-day activities without sacrificing time or money that could otherwise be put to use in implementing features.

A better title for Crosby's book should be QualityIsCheaperInTheLongRun?. With quality, the moral of Aesop's famous fable should be: Two birds in the bush are worth one in the hand.

QualityIsNotFree. But it sure beats the alternatives.

-- ScottJohnson

Alternate View

I suggest that the strawman argument proposed does not reflect the concept that quality pays in the short term. The strawman puts forward the proposal that it is less costly to do a shoddy job. Contrary to what is described above, the proposal is most definitely that the most effective and efficient ways to develop code also produce the highest quality code. Adding more testing and more reviews does not improve the initial quality of the code. By developing high quality code from the start, we can start eliminating the need for after the fact reviews and testing. This is particularly true of the approach proposed by WilliamEdwardsDeming and to a less obvious degree the approach proposed by Philip Crosby in QualityIsFree. Do not slow the process down to improve quality, improve quality to speed the process up.

-- WayneMack

Please note that Crosby stated himself that there is a price for conformance and a price for non-conformance. His reasoning basically says that the price for conformance always, always, ALWAYS comes out less than the price for non-conformance, so quality is, in fact, free. Decades of real world examples have proven Crosby and others who espouse this approach to be correct. -- MartySchrader (hoping the stupid-ass Sharkbot will stop reversing properly done edits)

See: QualityElbow

CategoryQuality