Poka-Yoke Your Code

Pokeymon says "Don't forget to Poka-Yoke your code, kids!"Mary Poppendieck tells this great story about when the manufacturing plant she worked for transitioned to Lean. When they started, she says, they had this separate QA group whose job it was to find defects in the products after they were already made (sound familiar?). But then they took these QA folks and moved them out onto the production line to figure out how to make stuff without defects in the first place. Huh! Wouldn’t it be cool if we could do that for software?

This is the idea behind Poka-Yoke, or mistake proofing. It means setting things up in such a way that prevents people from making mistakes.

You’ve probably seen this before in product design – monitor cables with male & female ends that prevent us from plugging them in the wrong way. Or in software with controls like dropdown lists (male, female) that prevent users from entering incorrect values (I’ll let you use your imagination).Monitor cables have male & female ends to prevent us from plugging them in the wrong way

Toyota brings this idea onto their production lines with devices that prevent incompatible parts from fitting together. But also with poka-yoke methods that detect problems and shut down the machine (stop the line) or activate alarms so people are immediately alerted to correct it. So even when it’s not possible to completely prevent errors from occurring, they still prevent those errors from entering production. And they can then fix those errors immediately before they get a chance to compound into serious problems.

So, okay. How do we poka-yoke our code?


If we’re using a compiled language then our compiler prevents language-specific errors from entering the software –- it won’t even build the software if it detects errors, right? So we can start by designing our code in a way that actively pushes things up from run-time detection to compile time detection. Using thing like using generics and favoring objects over primitives. And avoiding hacks like hiding things in String or Object types that might feel flexible but that allow IBM 29 card punch machine (NOT a modern langauge)errors to sneak right past our first poka-yoke.

Modern Languages

We can build on this idea by using modern languages that are specifically designed to prevent common programming errors. Things like functional languages that use immutable values and methods with no side effects that make our code safer by preventing us from making those mistakes in the first place.

And if we’re stuck with older languages, we can still learn about the newer languages & incorporate some of their ideas into our own code to make it less error-prone. Stephan Schmidt (@CodeMonkeyism) wrote an excellent post on this Go Ahead: Next Generation Java Programming Style that I highly recommend.

Automated Tests

Well, this is all lovely, but of course it won’t find even the most basic of application errors. So, like Toyota, we need to supplement our builds with poka-yoke methods that detect problems and  alert us to correct them. We’re probably already using automated tests to validate our application logic –- issues our compiler can’t catch. So what we can do are employ our own poka-yoke techniques to give us better coverage and that truly “stop the line” to prevent errors from moving forward. Things like:

  • Using TDD & ATDD to ensure we don’t write a line of production code without test coverage to poka-yoke it.
  • Continuous integration boxes that alarm when these tests fail so we’re immediately alerted to fix them.
  • Tools & scripting languages that automatically run the appropriate test suites on check ins and deployments and to prevent (or at least alarm) us from taking those actions upon failure.

Exploratory Testers

Okay, but what about all the stuff we don’t think to put in our tests (it breaks when you do what?!). This is where we need to take our Testers (aka “QA Folks”) and move them out onto the production line (yep, right there in our programming spaces!) to figure out how we can make stuff without defects in the first place.

I know, we’re really super smart and all, but software development is hard. And if we knew how to make software without defects in the first place, well… then you probably wouldn’t have read this far down in this post by now (and if you did, feel free to share your secret with the rest of us in the comments).

We are really good at building software. But we need another perspective. While we’re focused on how to make things work, it’s helpful to have people focused on how things might break so that we can then feed that knowledge into what we’re building to prevent those defects from happening in the first place. This means things like pairing programmers & testers on each story so we’ve got that tester right there on our coding floor with us doing exploratory testing early & often. And it means feeding their results into new automated tests that then become part of our poka-yoke.

Even at Toyota they can’t know from day 1 all the things that might break. Instead, they employ processes that are continually inspecting for problems in the system and, when one is found, they take steps like adding new poka-yoke methods to prevent it from ever occurring again. Wouldn’t it be neat in software if we found a way to stop repeating our same mistakes over again? 🙂

I have obviously only barely scratched the surface here, so am hoping this post will generate more ideas. What ways can you see for poka-yoking your code? How can we evolve these ideas to really make them work?


8 responses to “Poka-Yoke Your Code”

  1. First a confession: When you twitted about writing this post, I thought I will disagree with it. Now that I read it, I *agree* with it. Maybe I would put a little less emphasize on “compilers” because that tweaking the program such that the compiler will catch more bugs is a bottomless pit: you can always do more, and you never get enough.

    Anyway, other things the help in poka-yoking:

    (1) Design By Contract – Although not as effective as automated testing, it does provide a systematic way to catch runtime errors

    (2) Plugin-based design. If a program is structured as a collection of plugins – where each plguin supplys a single user-visible functionality – one can easily turn certain functionality off while retaining all other functionality. This is a very effective method for detecting bugs (I even blogged about it not long ago). Moreover, even if you didn’t manage to fix the bug, you can still deliver a working product (sans the buggy plugin) thus preventing tremendous emotional/financial pressure.

  2. Abby Fichtner Avatar
    Abby Fichtner

    awww, I was looking forward to that counter argument you were preparing 😉

    Excellent point on Design by Contract – isn’t one of the ideas with that that you figure out each method’s preconditions & post conditions and then put asserts right into the code so that if you, say, pass in a value that doesn’t meet the pre-condition it asserts and you get that immediate failure? (or am I confusing ideas?)

  3. Yes, DbC is exactly this thing. in Eiffel it is supported by the language so it has some additional capability (like running an method that checks the invariants of the current object after a public method is returning). In Java you can emulate the basic capabilities (preconditions, postcondtions) by placing assertions at the beginning/ending of methods. I typically do that by declaring a DbC class with static methods such require(boolean b, String s) and ensure(boolean b, String s) that fire an AssertionError if b is false.

    Anyway, just to get the priorities straight, DbC is less effective than testing for two reasons. First, in many methods the DbC code ends up being just as complicated and error prone as the method’s actual functionality code, which is rarely the case in testing. Second, DbC does not capture the data that produces a bug. It only captures its manifestations. Thus there is no notion of automatically exercising the program to see if something is broken.

  4. Excellent post, not only because you mention me 😉

    Contrary to most others I still believe compile time typing is Poka-Yoke and helps with preventing bugs. Using classes instead of Strings or primitives (CustomerNumber, Quantity, …) is Poka-Yoke too.

    Keep up the good posts, thanks for the insights

  5. Abby Fichtner Avatar
    Abby Fichtner


    huh, that’s really interesting about how it compares against testing in effectiveness – thanks for explaining! It still seems a great poka-yoke though for it’s way of failing fast & obviously. I can see how tests are more deliberate in explicitly checking for conditions, but DbC does feel like a good additional safe-gaurd, so a good tool for us to have. Curious why we don’t see more of it…

    @Stephan – thanks! And please by all means point us to other posts of yours that speak to this.

  6. Abby Fichtner Avatar
    Abby Fichtner

    Decided on Echo for blog comments, seems nifty. Thx to all who gave suggestions.

  7. joshilewis Avatar

    I like the ideas in this post. However, from what I understand, the concepts and techniques you're describing fit more into the notion of Jidoka – building quality into the line. A poka-yoke is one mechanism used to implement/achieve Jidoka. A poka-yoke is a mechanism for a worker to stop the line when a defect is detected.

    Also, in my opinion, visual indicators of problems in the line are actually a form of Kanban (visual trigger for action).

    My thoughts are usually somewhat unformed, so I'm open to debate on anything.

Leave a Reply

Your email address will not be published. Required fields are marked *