Zero Inspection


Regardless if it is due to yourself or it was dropped in your knee by someone else, have you ever had problem with the quality of your software?

I know I have and I guess that all of us at some point in time have been in the situation where we face an ever growing number of bug reports.

I’ve been reading Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck and in it is short section on the idea of zero inspection, which is an idea presented by Shigeo Shingo as a part of Just-In-Time production.

The Poppendiecks write:

”The idea behind autonomation is that a system must be designed to be mistaken-proof. There should not be someone looking for a machine to break or testing product to see if it is good. A properly mistake-proofed system will not need inspection.”

”Mistake-proofing assumes that any mistake that can be made will eventually be made, so take the time at the start to make the mistake impossible.”

My interpretation of this is that when implementing zero inspection in a programming context you should use practices allows you to automate as much as possible. Practices such as…

  • Programmers perform test activities – mentally accepting that testing is a part of a programmers daily tasks and not something that is performed by ”some else”.
  • Design by Contract (DbC) – to specify the pre and post conditions when designing an interface
  • Test Driven Development (TDD) – to automatically test individual components in your system
  • Acceptance Test Driven Development (ATDD) – to automatically test the entire system
  • Continuous Integration (CI) and Delivery – to automatically detect changes to the source code, run the tests to verify that the source code still works as expected and deploy the new code into production.

What do you think? Do you agree? Have I forgotten anything?

Leave a comment!