Zero Defect Software

by Krishna on August 27, 2009

Tim Barcz has an interesting post about striving for software with zero defects:

I think we should not shy away from holding ourselves to an excessively high standard.  Frankly, I’m more familiar with how to do it as a developer having years of building software to gain knowledge and experience from.  I don’t have all the answers on how do this from the other aspects but I don’t think this means we stop trying.  I think quality should be the first and highest goal.  Speed should follow quality.  If you’re keeping a high quality standard and feel overwhelmed that the work is backing up behind you and you can’t ensure the highest quality, please don’t hesitate to talk to me about it and we’ll see if priorities can be reworked.

I agree with the general principle in the context of Tim’s work environment, which seems to be software development in a large company. Within that context, it makes sense to strive for as much quality as possible. I also like Tim’s statement, “Speed should follow quality”. This is important because only by explicitly stating that quality supersedes deadlines will you get the required behavior from your team members.

If you want better quality, it is not sufficient to just set goals. It is also important to make sure that your team is aligned towards achieving that goal. This means when it comes to decisions that require prioritizing quality and something else, you always choose quality. This is not easy, especially when the benefits of quality take a longer time to materialize and the effects of delays in project deliverables are more visible.

Having said that, striving for zero defects does require taking note of the following real world situations:

  1. Bugs will still occur for a variety of reasons. You still need to plan for handling them after the fact. As they say, hope for the best, prepare for the worst.
  2. Any high-quality environment necessarily requires closer review of bugs to avoid future occurrences. Take care to stay focused on processes and not on people.
  3. A low number of bugs could result in statistical anomalies such as disproportionate number of bugs from a few persons. Be careful how you interpret such data.
  4. Be mindful about the opportunity cost of fixing every single bug, especially those which could be resolved by less expensive methods (changing the hardware/software environment, training and so on)

Also be careful of unintended consequences. A strict focus on low number of bugs could result in developers trying to reduce “bug count” instead of actual bugs, by re-classifying bugs or simply not reporting them. Avoid situations where metrics can be gamed.

I don’t remember the book I read this, but there was a case study about how the hospitals that reported more errors had better quality healthcare. The reason was that the doctors and nurses in those hospitals were not afraid to report their errors and so were able to honestly discuss them and find ways of preventing them in the future. The hospitals reporting fewer errors were focused on error count which were probably tied to some draconian reward-and-punishment system.

In other words, quality has to come from the bottom-up. Trying to enforce quality from the top can lead to distortions. Tim seems to be advocating the first and I am all for that.

{ 2 comments }

Pallavi August 28, 2009 at 11:28 am

I am no programmer but the last case study methodology would apply to any quality improvement as you rightly pointed out as to be bottom-up approach and not the other way.

Krishna August 28, 2009 at 2:00 pm

Pallavi, that is absolutely right. Unless the people in the trenches accept quality, any top-down approach is bound to fail.

Comments on this entry are closed.

Previous post:

Next post: