BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

The Holy Grail of Zero Defect Systems

by Vikas Hazrati on Feb 22, 2011 |

While, zero defects sounds very good to hear, is it really possible or is it an unachievable goal? Many organizations adopt a 'zero defects methodology'. Does it really mean anything?

According to Jim Bird, the cost of 100% perfection is extremely high. Once teams reach the optimal level of 90% defect removal, the returns from further removal of defects is significantly lower for the unjust cost associated with it. Jim, quoted Ken Beck and Martin Fowler's book 'Planning Extreme Programming' in which they mentioned,

For most software, however, we don’t actually want zero bugs. Any defect, once it is in there, takes time and effort to remove. That time and effort will take away from effort spent putting in features. So you have to decide what to do.

Likewise, Michael Dubakov suggested that having a Zero defects mentality might create more problems than the benefits that it can bring. According to Michael, the unpleasant effects include

  • 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.

Michael suggested that in reality having bugs in a production system is normal. This does not mean that teams should get complacent and avoid fixing bugs. However, this does imply that the so called 'last bug' is a mirage.

Jim suggested that one should be selective about the bugs that need to be fixed. Teams should first determine the importance of the bug to business operations by validating its severity and frequency. As a next step, technical factors like 'cost to fix' and 'risk to rest of the system' need to be considered before going ahead with the fix.

Zero bug tolerance naively assumes that it is always good, it’s always right, to fix a bug. But fixing a bug is not always the right thing to do, because with any fix you run the risk of introducing new problems

Joel Spolsky suggested that Zero defects does not mean zero in the literal sense. It means that at any given time, the highest priority is to eliminate bugs before writing any new code.

So what are the best ways to minimize defects?

Mark Windholtz, placed significant importance on TDD when he suggested,

Test-First coding that is fundamental in achieving the goal of Zero Defects. Test-First coding requires that an automated unit-test is written before the production code and the test-to-code cycle time be 5-15 minutes long.

Likewise, Michael Dubakov suggested a combination of TDD, continuous integration, automated regression suite, root cause analysis and high development skills to reduce the number of defects.

Rolf Gotz mentioned a list of 10 principles for getting to zero defect systems. Some of them included

  • Customers and software developers who like each other.
  • Small and easy scope of your requirements, increasing in small steps.
  • High-value requirements are the initial focus.
  • Acceptance criteria are paramount.
  • Problems first (then the requirements).
  • Performance requirements first.

Thus, though the system should have minimal defects, striving for zero defects is an unending goal. The key lies in knowing when to stop. As Jim advised,

Knowing when to stop fixing bugs, when you’ve reached the point of diminishing returns, when you should focus on more important work, isn’t easy. Knowing which bugs to fix and which ones not too, or which ones you can’t or shouldn’t fix now, isn’t easy. And you will be wrong sometimes.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

What is a defect? by Udayan Banerjee

Another important point to consider is what you classify as defect. Is it about creating a set of test cases and ensuring that all of them pass? Will TDD always ensure zero defect?

setandbma.wordpress.com/2008/06/14/agile-adoption/

Zero Defect Policy May Help As Well by Umesh Tiwari

We have a zero defect policy implemented as a quarterly objective. I have seen it has driven a lot of process and practice changes along with an increased emphasis on quality which is helping us write quality bug free software. But we are implementing this policy in an incremental manner. As we are following SCRUM , it is further helping us to incrementally reach our goal of a defect free system.

If you look back Toyota production system... by Xiong Jeff

"Zero Defect" actually means "finding root cause of any defect and improve the process so that similar defect could never happen again".

It's non-sense talking about if it's worthy or not to fix each and every bug. It's all about recognizing the ineffectiveness and inefficiency in your production process and improving.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT