Zero Defects

[Please note that this page has a great many problems with inaccurate assumptions, StrawMan arguments, etc. It needs some serious cleaning up.]

Described in QualityIsFree by Phillip B. Crosby, ZeroDefects is a standard of performance management that adopts the attitude of defect prevention, to DoItRightTheFirstTime. Anything else is admitting defects are acceptable.

Quality is defined as "Conformance to Requirements". Note that this is not the same as "Conformance to Specifications"

[That statement is totally incorrect. Specifications are the distillation of requirements into a set of measurable criteria. Arguing over semantics gets us exactly nowhere.]

Discussion

Building something according to specification that fails is not a defect. Building something that works, but disagrees with the specification is a defect. The assertion is: it is "better" to build-to-specification than to build-to-intent (i.e., undocumented requirements or expectations).

It must be noted that specifications follow requirements. The ultimate goal is to build to requirements so specifications must be carefully developed. Read about this in Mr. Crosby's book where a company's teleprinters were not passing the quality checks because of incorrect specifications even though they they matched the requirements!

What about errors in Specification?

Discussion

Building something that doesn't work (or otherwise fails to satisfy expectations) is a requirements bug. You apply Error-Cause-Removal, and institute something like RequirementsManagement.

Mr. Crosby gives "contract errors" and "order description errors" as examples.

It might be a mistake to read Mr. Crosby's ZD case study as a prescriptive approach to quality improvement, as opposed to a pattern for quality improvement. Mr. Crosby doesn't go into a detail discussion on requirements or specifications, but presumably this is covered by the 'Make Certain' section of the book which applies to the paperwork chain. Specific questions asked include, "Who is the ultimate customer, the one who uses the product or service of the company?" and "What specifically does the customer want from us?" (p 248)''

The selling point of ZD is the conciseness and precision of the message that "Zero Defects" conveys.

Discussion

The author, Philip B. Crosby, repeatedly emphasizes that the ZeroDefects concept is not a motivation program.

What is the message the "Zero Defects" conveys?

Sometimes, yes, the message that mistakes are to be avoided (or at least, not repeated) is necessary. We should aim to have no defects in the service we deliver. We'll fail, of course, and that's not a cause for self-flagellation. But we should always look to take away the causes of mistakes.

ZeroDefects should be the goal of any quality improvement program.

Discussion

What about alternate approaches as espoused by people such as Dr. Joseph Juran and WilliamEdwardsDeming? They say that ZeroDefects is not sufficient.

That should read 'Zero defects should be the goal...', i.e., as an expression of an ideal, rather than in specific reference to the ZD program as described by Crosby. FYI: an example of Juran's criticism of ZD can be found at http://www.juran.com/research/articles/SP6610.html

The assertion is: it is "better" to build-to-specification than to build-to-intent"

Discussion

ZeroDefects, as specified by Mr. Crosby, clearly delineates testing from implementation and requires that these be handled by separate peer level organizations. I am not sure that ExtremeProgramming would fit with the ZeroDefects environment.

Sure, I didn't mean XP was a ZeroDefects thing. Just that XP'ers might agree with the assertion.

Actually, Crosby says acceptance testing should never be done by the engineers. (p 61) As for the assertion, it may not apply to XP since one of the justifications for OnsiteCustomer is to resolve disputes, such as gaps between specifications (story) and intent (end user expectations).

I think the assertion may apply to both, but I think there may be differences in interpretation. In Mr. Crosby's approach, it appears that the interpretation of the specification is solely in the hands of the quality department and developers can only question the specification in cases where they cannot implement it. In XP, the interpretation of the specification is in the hands of the developer, and the developers can suggest changes in the specification for various reasons.

OK. However, in both, the belief is only the client can decide on what is correct.

No, the client does not figure into ZeroDefects; the client merely gets what we decide to develop. The only thing the client gets is a specification that is supposed to accurately describe the product (See "Quality Is Free" page 160).

Does the ZeroDefects Specification map to the XP UserStories, AcceptanceTest, UnitTest, CodingStandard, something else, or none of the above?

Discussion

Isn't "conformance to specification" the XP way? Build to the UserStories, not what improved UserStories you could invent.

Mr. Crosby talks about both ZeroDefects and Continual Improvement. Are these two concepts contradictory?

Discussion

In QualityIsFree, these appear complementary. Zero defects is the goal. ContinualImprovement is one of the steps in getting there.

If you are doing ContinualImprovement, does this mean that a work standard of more than zero defects is acceptable? Once you achieve zero defects, does this mean that ContinualImprovement is no longer necessary?

It just means that you have to start measuring your ContinualImprovement on another axis besides the number of defects. Perhaps cost, or ROI or even SoftwareInProcess (http://groups.yahoo.com/group/softwareinprocess)?

So continual improvement is not about reducing defects (assuming Mr. Crosby's definitions for both terms)? What is being improved?

Since no software project can ever reach zero defects, why use such a name? It is not a reachable goal: It is self-defeating.

It's a target to strive for. The proponents of ZeroDefects argue that setting any lesser target ("less than 10% of clients report a defect", for example) sends the wrong message and encourages low quality work - and so that is self-defeating.

Zero defects is a false target. Each month, each project will fail to achieve zero defects. The only way to achieve zero defects is to not release complex software. Perhaps a better goal is "Reduce Defects" which is obtainable. Each month, each project can have less defects then the month or project preceding it (however the defects are counted.)

A target is something to aim at, not necessarily to achieve. And, anyway, given that the number of defect is an integer, your goal is the same thing, ultimately.

Actually, Mr. Crosby states over and over that zero defects is reachable and it is management's responsibility to demand that it be met. It is okay to disagree with the feasibility of zero defects, but one cannot redefine the meaning. Be careful what you ask for when you start looking at zero defects.

I've only skimmed this page but several points jump out at me. I think most developers have heard management insights such as "write good code, and do it faster" enough times that something along the lines of "zero defects" is going to be dismissed as just another impossible goal. Certainly a goal without buy-in is self defeating.

To me a better goal is "continual quality improvement". It is measurable and possible without being discouraging. We know that we'll never hit zero defects, but with continual improvement we can continue to approach it.

Another point to be made is that fixing defects does not necessarily increase the value of the software. If a defect has a minor impact and the customer is requesting a feature that adds great business value and customer satisfaction, then surely correctly implementing the feature is of more value than fixing the defect.

Also, anything that overemphasizes conforming to the specification is a little dangerous. Most developers I know don't like to deal with requirements gathering/management and customer acceptance. The temptation to promote "conform to spec" to mean "assume that the spec is perfect" is going to increase defects and lower quality if you measure by customer satisfaction and delivered value. Without customers, none of this matters.

I believe that value is just as important as quality when evaluating process and improvement.

--David Beardsley

Most developers I know don't like to deal with requirements gathering/management and customer acceptance. The temptation to promote "conform to spec" to mean "assume that the spec is perfect" is going to increase defects and lower quality

But they don't deal with requirements gathering etc, how are they to spot problems with the spec? If your developers aren't talking to the client, I want them to follow the spec as if it were perfect. Anything else and they're just guessing.

Remember, however, the specification is not the full design. It is full of gaping holes to be filled by guess (in lieu of any other method). The problems occur when the guesses made by the developers differ from the guesses made by the testers/QC/QA department.

See: QualityIsFree, DoItRightTheFirstTime

CategoryProcess, CategoryQuality