Chase's & Stewart's Mistake-Proofing is a useful read about the theory and practice of avoiding mistakes in manufacturing and service. It is a short book and so just skims the surface of the field, but it gave me enough information to better understand some problems my software development organization has with its "manufacturing."
The problem we have is that we don't so much have a data pipeline with state change at the joints, ie fixed points in the flow, but more a leaky data pipe where the leaks are the state changes. (We inherited much of this code from a systems integrator hired before my time.) Changing the whole flow is not possible right now and so how can we mistake-proof the leaks?
Mistake-Proofing advocates poka-yokes as a means to avoiding mistakes. The term is from Japan, where all the quality focused manufacturing ideas have come from since Deming arrived after WWII! It means to avoid (yokeru) mistakes (poka). We see them all the time all around us. Some are actual devices -- the car engine won't start unless the clutch is depressed -- and some are conventions -- hot water is on the left. In software, a common poka-yoke is method argument checking. For example,
public void m( String v ) {
if ( v == null ) throw new IllegalArgumentException("v must not be null");
...
Other, more complicated poka-yokes are based on the satisfaction of accumulated conditions. For example,
if ( ! ( x && y && z ) ) throw new IllegalStateException("...");
So, Mistake-Proofing has given me a renewed inducement to improve our system and a nomenclature to use.
Note: I find negating a single conjunction of conditions, ( ! ( x && y && z ) ), more readable than a disjunction of negated conditions, ( ! x || ! y || ! z ). Code readability is itself mistake-proofing.
