Poka-Yoke is Not a Joke (2010) | Hacker News Reader

Poka-Yoke is Not a Joke (2010)

hbr.org

41 pointsboredgamer225 comments

Wait, ARE TYPESYTEMS POKA-YOKE FOR PROGRAMMING?!?!?!

On of the well known Poka-Yoke strategies are cables that can not be plugged to the wrong port since there is a different one for everything. Kind of relates well to function signatures that make sure only the right type of data comes in.

That's how I see static typing in languages, yes. I've not yet experienced the languages that offer the purported transformation of the way of programming, in which you spend 90% of the time designing the types, 10% cleaning up, and the program magically works. So for me, static typing is quintessential programming poka-yoke. And that's why I like it.

Another Poka Yoke system for programming are asserts.

It's not that simple.

You can easily design type system + compiler, which will have destructive "attitude".

It's no different from human interactions and how being "right" is not always "being constructive".

Best type systems have low mental overhead, can be selectively applied (to benefit when it's profitable, and to avoid costs where it's too costly), are humble, and are good companions by helping developer learn the domain space.

E.g. 1 there are good blog posts describing how you can write Haskell code by just asking Haskell compiler what type is needed to fit with the rest of your code. Step by step you fill in the blanks.

E.g. 2 there are good videos from Clojure about how you can follow types to implement a new idea.

Counter example: Neither 1) nor 2) is possible in C, and yet you pay hefty price mandated by C type system.

All 3 type systems have their own trade offs. Picking one that is most aligned with goals of your project does have impact :)

What C has isn't really a type system, it's more a system for expressing storage characteristics. Custom types are cumbersome, polymorphism is nonexistent, but blatant errors are not prevented.

Yes absolutely. Linters too!

"parse, don't validate" (https://news.ycombinator.com/item?id=21476261) too. An API that prevents you from doing the wrong thing too. Banning a dangerous function too (that's linting, I suppose).

Not all poka-yokes are as elegant as the ones in the article. A friend once told me about a poka-yoke measure put in place in their factory after someone left a wrench in an airplane engine as it was being assembled (leading to millions of dollars of damage).

Tools were stored in a special toolbox. The tools each had a slot to be stored in (the slots were foam, cut in the silhouette of the tool, so only that tool could be stored there). Each slot had a sensor to tell if the tool was there. You had to scan your ID to open the box. A computer system logged which tools you took, and you could not punch out your time card until all your tools were returned.

The system was complex and costly to build, but less costly than a single mistake like the one that inspired it.

Curiously this sounds like a system that would be useful to lots of workplaces where hand tools curiously go missing!

https://www.seattletimes.com/business/boeing-aerospace/boein...

https://en.wikipedia.org/wiki/Retained_surgical_instruments

Variations on the foam cutout or outlines of tools have been in workshops for at least a century, as good tools are expensive. Its not done everywhere as it’s a pain to setup, and you need discipline to keep following it.

Preventing surgical instruments is easier the more expensive the tool is. Anything over $5 can easily get a RFID tag and you can simply scan the patent then the work area to get accountability. The hard part is with gauze and other cheap items that can’t easily be tagged, and will be going inside the body, so they have very high biocompatibility requirements (eg: inks in spectrum transparent to blood might be too toxic to use).

Many things like gauze sponges can be given a few radiopaque threads and an X-ray is taken after the surgery. It’s still no substitute for a good count of materiel.

Handtools probably go missing more often than socks or pencils. It would be great to have a cheap NFC based system for even smallish workshops.

This technique is part of 5S, another bit of the Toyota Production System. Poka Yoke is part of Kaizen, IIRC.

Poka-yoke is a massively useful concept in the design of physical objects, and it should apply to design of software interfaces as well.

A key principle is making different things look different. In a mechanical assembly, often you see very different pins and fasteners doing similar jobs - but what may seem an oddity on the part of the designer is a godsend when assembling. I'm sure we've all puzzled over putting together household objects where you have several slightly-different lengths of the same screw. In software, consistency is incredibly important, so that users can expect behaviours and discover features, but there's still a case for making different things visibly different.

Even some code writing practices exist with the goal of "making the mistake impossible to be made". E.g. in C or C++ introducing the practice of writing the constant first in the conditionals:

    if ( 0 == x )

makes the mistake of accidentally writing assignment there impossible (0 = x would generate an error). However, my belief is that we should both demand and expect from the tools to have the "reasonable defaults" i.e. even if the

    if ( x = 0 )

is a valid code, the "reasonable default" of the compiler has to be at least a warning. But who says that the environment where the compiler is used has "reasonable defaults" itself? I've worked in some environment where it was really expected from every participant to "ignore the warnings" produced during the build process. Which just shows how hard it is in some environment to even start a culture of "making the errors less possible": "don't waste the time, we have other methods to detect the problems, just do how it is done here" etc.

Viewed from the higher level, it is always about human weaknesses, still, it's always harder to address such weaknesses present on the higher levels.

One of the human factors that makes makes touch screens in cars so dangerous.

Poka-yoke plays a big role in making my life easier. I implemented a bunch of them around the house, and in the garage. They're an excellent coping mechanism for people with ADHD, because they make it hard to do the wrong thing.

- I leave my backpack against the door to make sure I don't leave the house without it.

- I put coloured tape around the 10 mm spanner, and the 10 mm socket. The 12 mm socket is 2 sockets to the right.

- Every tool has a place. If a slot is empty, a tool is missing.

- When I disassemble something, I place all the screws down in order. When I put everything back together, I should always need the rightmost screw.

- I always do mise en place before cooking. If an ingredient is missing, I'll know before I start cooking.

I also try to implement them in the workplace. Errors can happen, but they shouldn't happen twice.

The author's Poka Yoke measure to filter words from email reminds me of my own email Poka Yoke ritual. Before writing or replying to a lengthy or important email, I type some gibberish in the address field. This ensures that outlook/gmail prompts a confirmation if I accidentally hit send.

This is a nice article.

I've been incorporating ReadMe.md files in most projects and folders, as well as self documenting Makefiles, with their default target set to help so that it displays something informative about what it will build.

Most of the times I try to include some sort of testing, or alternatively generate index files about the dependencies needed to build.

This has helped me remember the essential parts faster when I revisit projects that haven't been in my mind lately, thus I avoid mis-typing commands and 'forgetting' information.

Reminds me of this anecdote an ex-colleague told me: he was working at GE on an x-ray machine they use during cardiac catheterization to monitor the catheter as it moves from your groin towards your heart. The machine recorded the whole procedure, and there was a "replay" option to evaluate the findings I guess. One day they got a bug report which asked for a more prominent warning on the UI if the device was currently in "replay" mode. It turned out that there was an incident where a doctor only realized midway through the procedure that they were looking at the replay footage from the previous patient...

Dang, that's scary! Cath labs are amazing if you ever get a chance to tour one - not as a patient of course.

You could make your documentation generator detect if any functions are completely missing documentation. Then in addition to printing "No overview available" in the docs, it could also flag a warning -- and in Release mode, an error. Not that I'm bitter or anything.

Are they rhyming yoke with joke or vice versa?

You'd be forgiven for thinking so! It comes from Japanese, yoke (除け) meaning protection and poka (ポカ) meaning blunder, careless mistake, or error. Although it looks as if it would rhyme with joke, it's more likely to be said yoh-kay. If you're curious, paste ポカヨケ into Google translate, select Japanese, and hit listen :)

(I suspect OP knows this -- the question I think was meant to be a sly way to say "are you supposed to say yoke like yolk so that it rhymes with joke, or joke like jokay so it rhymes with yoke")

IPA /ˈpo̞käˌjo̞ke̞/

Reply on news.ycombinator.com