Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Poka Yoke

en.wikipedia.org

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Poka Yoke

#11

Post by aaron695 »

This is probably bad advice. The Japanese definition is a little different too - https://ja.wikipedia.org/wiki/%E3%83%9D%E3%82%AB%E3%83%A8%E3...

> defects by preventing, correcting, or drawing attention to human errors as they occur.

There seems confusion on what this applies too (The Japanese Wiki includes workplace accidents) but specifically within Health and Safety it's too broad to put these into one word, you'd assume something like this also applies to non-critical processes -

https://blog.sliceproducts.com/safety-hierarchy-of-controls

Safety Hierarchy of Controls: A Brief Overview

  Elimination
  Substitution
  Engineering Control
  Administrative Control
  Personal Protective Equipment (PPE)
In network security, Elimination is taking away a risk, like stop using Confluence. PPE would be cyber insurance. Software engineering, Elimination - Remove frameworks.

But you won't just "Poka-yoke", which seems to be 'Engineering Controls', 'Administrative Control', 'PPE'

Re: Poka Yoke

#12

Post by sokoloff »

One of my favorite examples is the control lock on some light aircraft. Aircraft are often parked outside and in windy conditions, you want to prevent the control surfaces from being banged around, so you put in control locks.

You also don’t want aircraft trying to take off with locked controls (such as the G-IV mishap at Bedford* a few years ago).

Enter the control lock that blocks the starter: https://www.csobeech.com/images/ControlLock-Late-36_58.jpg

The pin on the right locks the yoke (ailerons and elevator), the clip retains it from falling, and the rudders are locked with the spring pin. The red “flag” part with the lettering extends to block the magneto (ignition) and starter controls.

* https://en.m.wikipedia.org/wiki/2014_Bedford_Gulfstream_IV_c...

Re: Poka Yoke

#13

Post by jihadjihad »

The Apple power brick's metal knob that prevents backwards insertion is my favorite example of poka-yoke. MagSafe is another one, too.

Re: Poka Yoke

#14

Post by DavidPeiffer »

sokoloff wrote: post #12

One of my favorite examples is the control lock on some light aircraft. Aircraft are often parked outside and in windy conditions, you want to prevent the control surfaces from being banged around, so you put in control locks. You also don’t want aircraft trying to take off with locked controls (such as the G-IV mishap at Bedford* a few years ago). Enter the control lock that blocks the starter: https://www.csobeech.…

I'm an industrial engineer, so this is all right up my alley!

My favorite example is a two-part foam injection machine. They needed to change the injection head, and accidentally put it on backwards. The parts mixed and worked their way back in the supply lines, solidifying along the way. Hundreds of thousands of dollars in lost productivity, multiple weeks to get it fixed. They promptly switched the coupling so it was impossible to put the injection head on backwards.

Re: Poka Yoke

#16

Post by AussieWog93 »

Slightly different to what is described here, but one of my pet peeves is the "nuclear button" features that devs put in their software - ie easy to activate features that add marginal utility to specific niche workflows but cause irreversible damage to everyone else.

Firefox deleting every single one of your pinned tabs on close if you have a second window open is an example of this, as is YouTube jumping to a different part of the video every time you bump one of the numerical keys on your keyboard.

Re: Poka Yoke

#17

Post by kesor »

More people need to know about this. Every time I ask some software dev if he knows the term Poka Yoke the answer is always no. Same goes for many operations engineers.

And when explained what it is, people assume it is the same as "idiot proof". No, it is not. Is a microwave door that turns the thing off when opened made for idiots? No, just regular people who want to use the microwave without frying their brain in the process.

Re: Poka Yoke

#18

Post by wheelinsupial »

nerdponx wrote: post #9
nmstoker wrote: post #6

Is this strictly a physical thing or can it apply in software?

Pretty much all good software design practices exist to prevent mistakes by constraining behavior. It would be interesting to try and formalize it and make it more specifically analogous to what's in manufacturing.

A process (Failure Modes and Effects Analysis FMEA) used to arrive at eventual error proofing in manufacturing has existed since the 1940s. There have been attempts to bring this process over to software. A quick search shows attempts in the 1970s.

I am really not sure why it hasn't caught on in software. I suppose the challenge is that you need to have specifications for what the outcome should be. In manufacturing this is always available. There is a design FMEA and a process FMEA, which typically correspond to the design and development of a product and the manufacturing process respectively.

This was covered in my mechanical engineering diploma program as something that is part of the mechanical design process. It also appears to be covered in some software engineering courses, but the application seems varied. Waterloo's SE 463 course covers risk management as applied to software project management (https://cs.uwaterloo.ca/~jmatlee/Teaching/SE463/Lectures/13_...), but for some reason seems to miss it at the design level. This is also covered in a book on software engineering: https://iansommerville.com/software-engineering-book/static/..., which is used for some software engineering courses at other universities.

I have provided some brief resources below:

Software: http://www.softrel.com/fmea%20overview.pdf

https://swehb.nasa.gov/display/SWEHBVC/8.5+-+SW+Failure+Mode...

https://www.witpress.com/Secure/elibrary/papers/SQM95/SQM950...

Automotive / manufacturing: http://www.phf.org/resourcestools/Documents/Mistake_Proofing...

https://www.aiag.org/event-presentations/S16QUALITY/ERROR_fi...

Re: Poka Yoke

#19

Post by luispa »

This was one of the best things I learned at my first job. The capability of finding an error-proof solution is so satisfying. One of the best examples I know is:

- The Heart Valves, are an error-proofing example in nature that prevent the back-flow of blood

Re: Poka Yoke

#20

Post by koolba »

I do this all the time for particularly scary yet infrequent scripts that I’m paranoid for accidentally executing.

The simpler ones check an environment variable such as RUN_SCARY_THINGY is set to “yes”.

The complex ones check that it has a timestamp that is within the past minute.

Accidentally run the script without exporting the right var and it prints a message suggesting a cup of coffee.

Post reply on HN