The initial term was “baka-yoke,” which means ‘fool-proofing’, but it was changed because the term ‘fool-proofing’ has dishonorable and offensive connotations. We Americans use a similar term: “idiot proofing” … which seems is even worse, but we don’t mind, do we?
Poka-Yoke (Japanese, pronounced PO-ka yo-KAY) which means ‘mistake-proofing’ or more literally – avoiding (yokeru) inadvertent errors (poka) – is the use of any automatic device or method that either (1) makes it impossible for an error to occur or (2) makes the error immediately obvious once it has occurred.
There are a couple of levels where this operates in software
In the SDLC – software development life cycle – we want the processes that are being executed to be as mistake-(idiot-)proof as possible … so we have high confidence that our product will be of high quality.
In the product itself … our requirements, design, implementation processes should ensure that the software product helps the user avoid mistakes.
When should we do this?
- when there is a process step where human error can cause mistakes or defects to occur, especially in processes that rely on the worker’s attention, skill, or experience – programming, code inspections, …
- At a hand-off step in a process, when output is transferred to another worker … programmer → QA → devops …
- Where minor early errors cause major problems later – e.g. getting the requirements wrong
- In the software product, where the user can make an error which affects the output
- In any case when the consequences of an error are expensive or dangerous.
Myths/Challenges
Because it originated as an industrial – a manufacturing – process, we can be led to believe that it doesn’t apply to software. After all, software is free to manufacture (reproduce) … these days we don’t even provide software on a physical medium (the youngest of you are saying “why would anybody do that?”), but poka-yoke is not restricted to manufacturing.
One software system with which I am extremely familiar, it is not only possible to make a mistake, but then have no way to recover – to fix the mistake – using the system. An expensive consultant needs to get into the database and manually (so to speak) adjust the data.
Even worse, you can get into a situation in the app where you are stuck and can’t get out except by force-quitting the app – we call that an oubliette.
A quick how-to:
Obtain or create a flowchart of the process. Review each step, thinking about where and when human errors are likely to occur. For a software product, use whatever design representation you have … you do have a design, don’t you?
For each potential error, work back through the process to find its source.
For each error, think of potential ways to make it impossible for the error to occur. Look for ways to:
- Elimination: eliminate the step that causes the error.
- Replacement: replace the step with an error-proof one.
- Facilitation: make the correct action far easier than the error.
If you cannot make it impossible for the error to occur, think of ways to detect the error and minimize its effects. Consider inspection methods, setting functions, and regulatory functions expanded on below.
Choose the best mistake-proofing method or device for each error. Test it, then implement it. Three kinds of inspection methods provide rapid feedback:
- Successive inspection is done at the next step of the process by the next worker.
- Self-inspection means workers check their own work immediately after doing it.
- Source inspection checks, before the process step takes place, that conditions are correct. Often it’s automatic and keeps the process from proceeding until conditions are right.
Setting functions are the methods by which a process parameter or product attribute is inspected for errors:
The contact or physical method checks a physical characteristic such as diameter or temperature, often using a sensor.
The motion-step or sequencing method checks the process sequence to make sure steps are done in order.
The fixed-value or grouping and counting method counts repetitions or parts, or it weighs an item to ensure completeness.
A fourth setting function is sometimes added, information enhancement, which makes sure information is available and perceivable when and where required.
Regulatory functions are signals that an error has occurred:
Warning functions are bells, buzzers, lights, and other sensory signals. Consider using color-coding, shapes, symbols, and distinctive sounds. In software we use pop-up warning or error windows (please provide relevant user-focused errors/warnings).
Control functions prevent the process from proceeding until the error is corrected (if the error has already taken place) or the conditions are correct (if the inspection was a source inspection and the error has not yet occurred).
#1 Challenge / thing to overcome
As usual, people. There is a certain amount of conscious reflection needed to apply this technique. Coding on autopilot perpetuates previous mistakes.
To recap …
Poka-Yoke technique is one of the highest value techniques in lean management. It is a way of ensuring quality without actually having a quality assurance process by preventing defects in the first place.
Poka-Yoke may be implemented in any industry – including software development – and has many benefits, viz.:
Helps work get done right the first time
Over time, it makes it more and more difficult for mistakes to occur
It’s “cheap as free” as strongbad would say …