Random Code

… or mistake proofing vs fool proofing.

Ayende recently caused something of an uproar on his discussion of repositories and query objects (see the post here and follow ups here and here).

The interesting thing about the responses is not that they argued against the underlying  architectural principles, but that the arguments seemed to be about protecting developers from doing dumb things.

Why is it that developers want to protect everyone else from the component / service / framework that they have just written / integrated?  Are we that afraid of the software we write that we must protect everyone else from it no matter the cost?  It was while reading another blog post that I stumbled across the perfect phrase for this approach – Baka-Yoke or “fool-proofing”.  

The problem with Baka-Yoke is that when you fool-proof something, the universe tends to create a better class of fool.  The other problem with Baka-Yoke is the cost.   The cost of using Baka-Yoke is a nasty multi-pronged beast:

• You have to write more code to protect that code you just wrote and now need to be “protected”
• Because you are restricting the use of that awesomely great gee-whiz powerful component you just wrote or  integrated, you loose some of the power of that component.
• You’ve lost flexibility and the ability to adapt to new situations – no longer can you weild the full power of the code you just “protected”, and to respond to new situations you have to write yet another adapter or bridge or some other form of abstraction to provide access to the functionality you now need.
• Perhaps the greatest loss of all; those “stupid” developers you are protecting – they will never learn about the underlying component or code you are “protecting”.  This means they will never be able to make intelligent decisions about it’s use or use it in new and previously unforseen ways to achieve great things (okay so slight exaggeration but you get my drift).

Instead of excercising Baka-Yoke, maybe you should consider Poke-Yoke?

Poka Yoke is the practice of “mistake-proofing” work. It’s another principle from the Toyota Production System. Poka-Yoke mechanisms ensure that the user or operator can’t make a mistake. For example a plug that can only be inserted correctly (like the 3 pin UK plug) or can be inserted in two ways that are both correct (like a 2 pin plug).

Poka Yoke is not Baka-Yoke or “fool-proofing”. The goal is not to prevent idiots from doing the wrong thing, but to make intelligent people do the right thing.

From Thinking for a Change - Beyond Jidoka – Poka-Yoke

We can practise Poke-Yoke without too much extra effort in software development.  The quickest and easiest mechism we have to mistake-proof our work is testing – automated, repeatable tests that can be run to verify that the method / component / application is operating as expected.  

I think the Baka-Yoke mentality is a holdover from times before unit-testing become as openly accepted as it is today (at least in the .NET world).  I think the fastest way past this mindset is the complete and utter acceptance of testing as an integral part of any development work – in essence the application of Poke-Yoke.