The Holy Grail of Zero Defect Systems

Posted by Vikas Hazrati on Feb 22, 2011

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Quality ,

Defects ,

Software Craftsmanship ,

Agile in the Enterprise ,

Software Testing ,

Testing ,

Agile ,

Bugs and Hotfixes

Share |

RELATED Research

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.

RelatedVendorContent

The Agile Tester

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Tutorial: Automating tests without compromising coverage of the environment

Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns

Combining Inspections, Static Analysis, Testing to Achieve >95% Defect Removal Efficiency

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

1. Back to top

   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/

   Reply

2. Back to top

   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.

   Reply

3. Back to top

   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.

   Reply