What is the Zero-Defects Mindset?

I think the concept of the zero-defects mindset confuses people.  Many agile proponents say that it inhibits creativity and risk-taking, and thus should not be an agile practice.  However, the goal is not so much to produce no defects, but to focus on doing the best work possible.

First of all, what is the zero-defects mindset?  Let’s go straight to the source for Microsoft’s definition:

“A best practice or principle of a successful team, it means the project team commits to do work at the highest quality possible at the time it is being done, and each team member is individually responsible for helping achieve the desired level of quality. The zero-defect mindset does not mean that the deployed solution must be “perfect” with literally no defects; rather, it establishes perfection as a consistent goal for the team to strive for.” [Microsoft Solution Accelerator glossary]

Many misunderstand this.  The problem is people hear “zero-defects” and think, “That’s impossible!  You can’t mandate perfection.  People are only human and make mistakes.  You shouldn’t punish them for making mistakes.”  Consequently, they think this rule reinforces bad behavior.

For example, Mary Poppendieck tries to use an analogy to the armed services.  If you read that article, the point she is really trying to make is that decision-making should be pushed down to front-line workers (this is the business concept of empowerment, which has been around in business for a while now).  I don’t see how that contradicts Microsoft’s definition above, do you?  Also, there is a huge difference between heroism in the military, where people can die, and developing software.  That is just too big a stretch for logic.

Joel Spolsky, former Microsoft employee and founder of Fog Creek Software, explains what the intended objectives of the zero-defects mindset really are:

“To correct the problem, Microsoft universally adopted something called a “zero defects methodology”. Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, “zero defects” meant that at any given time, the highest priority is to eliminate bugs before writing any new code.  Here’s why.

In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.” [The Joel Test]

Fixing bugs first, before writing new code… now that’s an agile principle if I’ve ever heard one.  Even with Test-Driven Development we know there will still be some defects that slip through somehow.  After all, you can’t predict how unpredictable the users will be!  But the end goal is 100 percent unit and acceptance test coverage with automated unit tests.  Sounds as close to the zero-defects mindset as you’re going to get.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

8 Responses to What is the Zero-Defects Mindset?

  1. Darrell says:

    Nitin – exactly my point!

  2. Nitin Rathod says:

    I accept the productshould produced with zero defect but it highly impossible for the human to produce the with zero defect.What can be done at the most is can be minimised not be eliminated.To hear or listen this phrase "zero defect" sound very nice and feels good but one has understand the fact.

  3. Darrell says:

    Jim – good question. If you are using Test Driven Development, your tests will be based off of the requirements document(s). If you then make sure to only write code with a failing test, then there will be a very tight linkage between requirements-code-test. The key is rearranging the development order to requirements-test-code!

  4. Jim D says:

    Unit tests don’t help if the code executes as the developer intended, but not according to the program specifications. How do we ensure traceability of the code back to the requirements/specifications?

  5. Darrell says:

    Udi, agreed. But the problem is certain agile proponents rail against it (maybe because they are in general not pro-Microsoft?) for the reasons noted in the linked article, and that is what I was trying to dispel here.

  6. Udi Dahan says:

    In agile development the daily build includes unit tests, regression tests, smoke tests, creating the deployable software, documentation, everything. Furthermore, breaking the build is the worst(?) offense. Whenever the build is broken, fixing it becomes priority #1. Thus, the "zero defects" mindset is actually prevalent in the agile camp, just under a different pretense.

  7. Darrell says:


  8. Steve says:

    I have accepted the zero defects mindset, and ever since doing so I haven’t written a bug…I like to call them "features" instead 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>