Zero Defects? Are You Kidding Me?
Are you familiar with zero defects mentality? It looks very good from the first sight. Zero defects... Let me think... Well, cool! I like it! I’d like to have zero defects in my projects.
So, what is zero defects mentality? Here is the quote from Lean Software Development an Agile Toolkit book:
“One of the fastest ways to kill motivation is what is called in the US Army a zero defects mentality. A zero defects mentality is an atmosphere that tolerates absolutely no mistakes; perfection is required down to the smallest detail. The army considers a zero defects mentality to be a serious leadership problem, because it kills the initiative necessary for success on a battlefield” — Mary & Tom Poppendieck
Obviously, zero defects mentality is not something that HOUSE M.D. likes ;) Moreover, I think Dr. House hates zero defects mentality. It causes several unpleasant effects:
- Not enough courage to refactor complex, messy, buggy, but important piece of code.
- Can’t make important decision, instead make less risky, but wrong decision.
- Do everything to avoid responsibility, that leads to coward and stupid behavior.
"Zero defects" may sound good. But in reality you still have errors after production. Even in predictable and (quite) easily testable industries (hardware, automobile, etc.) there are problems with 100,000 power adapters that should be replaced (or hard drive problems, or engine problems, I bet you can continue the list).
How can we expect zero defects in software development? It is harder to test, harder to define in details, harder to predict. Software development is a complex adaptive system, we can't predict all effects. Bugs in production is a normal thing, and by “normal” I mean we can't bring them to zero. We can (and should) minimize them using all possible ways, but The Last Bug is a mirage.
There are several obvious strategies that may help:
- Test Driven Development. Nice side effect of TDD is a unit tests suite. You have tests for new code, and you have unit tests for old code. More tests — less bugs.
- Continuous integration. Instant feedback helps to identify problems early and fix them early. It saves time (and money) and reduces bugs in production.
- Automated regression functional tests suite. Unit tests are good, but you need something else. Functional tests emulates user behavior and find user interface errors, integration errors, etc. Needles to say you should have continuous integration in place to succeed with automated functional tests.
- Root cause analysis. There are several ways to fix a bug. You may just hack the code and apply a patch (please, don’t do it at home!). You may think deeper and fix the bug nicely. Also you may look into the root of the problem and fix it. Yes, it may take time, but you will prevent future bugs from this domain.
- High development skills. Ironically, high skills do not always reduce bugs rate in production. “Stars” may be strong in some areas (business layer), but may not polish things. It may lead to many small bugs, especially on UI.
Is it a good thing to have "Zero Defects" goal in the sprint? The answer is "Are you kidding me? Zero bugs? It's a miracle!"
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)