Live data from Hacker News

Poka-Yoke

en.wikipedia.org

41–48 of 48 posts

Re: Poka-Yoke

#41
post #3

I like collecting little ideas like this. Slightly meta-ironically I'd describe the genre as "just abstract enough to be useful nuggets of knowledge" and I have an org file full of them. The hard part is I don't know any better name for such "concepts" so I can't search for other people's lists. Does anyone else keep a similar collect or have advice for finding more? (For example Gurwinder sometimes posts lists like…

I’m not sure if it’s similar to what you’re talking about, but there is something called “TRIZ” that’s a collection of “things” we were introduced to in a mechanical design class I took. https://en.m.wikipedia.org/wiki/TRIZ

I think TRIZ applies to software in some cases too, but I usually get down voted for saying so.

Re: Poka-Yoke

#42

In my industry, we mostly use the term to refer to mechanical features, typically keyways, that prevent connectors from being mated incorrectly. Suppose you have a module with 50 pins worth of connectors, but because some of the signals are in different harnesses which get installed at different times, you can't just use a 50-pin connector. For this example let's say it's sensible to break it up as 20+20+10. You woul…

The other solution is to make it trivial to both fix and detect errors, by using the same pinout so nothing gets damaged, and letting the computer tell you if everything is right. But with a car that's not really practical as things may not be accessible and easy to swap around.

Nor powered up at all stages of assembly.

I didn't spend a ton of time at the plant, but there was one notable visit where I got to camp out at the station where, for the first time, a 12-volt power supply alongside the assembly line would be temporarily patched into the half-completed vehicle. This allowed all the modules that'd been added so far, to boot up and do some self-checks. There were certain missing sensors and communication errors that were expected at that point and would be ignored, but plenty of errors that _would_ be raised so they could be fixed while they were still easy-ish to reach, before the seats and trim panels started going in.

Re: Poka-Yoke

#43
post #6

Earlier quoted context omitted.

> seeing how nobody pronounces Pokémon as Pokémon I say (and usually hear, from English speakers) "poker mon" (non-rhotically). Isn't that roughly correct, allowing for differences between English and Japanese vowels?

If you're going for "correct", the first two syllables should rhyme with "okay". That's what the accented é is trying to hint at.

I thought the accent was to indicate to English speakers that the word has three syllables rather than two? The acute accent isn't standard for marking a long vowel in romanised Japanese (it's usually a macron or a circumflex, or a doubling of the letter in ASCII-only contexts); and as best I can tell, the vowel in the original Japanese is short -- so closer to the "e" in "bed" or "met" than to the "ay" in "okay", if I understand correctly.

Re: Poka-Yoke

#44
post #15
post #13

Earlier quoted context omitted.

Still not sure what the phrase means tbh. A direct google translation comes back with "disabuse you idiot" So maybe it means "idiot proof"?

Yes, idiot proof would be a correct translation. Or more literally, since "détrompe couillon" is a noun, an "idiot proofer", or "idiot-proofing feature".

I see, thanks.

So "couillon" is a synonym for balls and idiot if I'm understanding the GP's references correctly.

Re: Poka-Yoke

#45
post #38
post #11

Earlier quoted context omitted.

"If you design something to be idiot proof, the universe will design a better idiot."

This one is funny, but I don't like this saying. It may be interpreted in a defeatist way that poka-yoke is pointless, because it can always be defeated, but in reality improvements that save almost all "idiots" are still worthwhile. An interlock in the microwave doors can't stop a better idiot from disassembling it, but it prevents a lot of everyday mistakes, and that's super helpful.

I have always thought of this saying as a warning that just because you have implemented a single layer of interlock doesn't mean that you are done.

For instance, let's say you risk electrocuting yourself if you insert a cable the wrong way. So the designers specify a keyed connector, which is the right thing to do. However, it is good to have in mind that some super-idiot will find a way to insert it the wrong way anyways. And as much as you believe in Darwinism, it may still be a good idea to mitigate the risk of electrocution if it happens.

Re: Poka-Yoke

#46
post #44
post #15

Earlier quoted context omitted.

Yes, idiot proof would be a correct translation. Or more literally, since "détrompe couillon" is a noun, an "idiot proofer", or "idiot-proofing feature".

I see, thanks. So "couillon" is a synonym for balls and idiot if I'm understanding the GP's references correctly.

I guess I should jump back in and clarify what I left unexplained when starting the thread.

Contrary to "couilles", which are indeed "bollocks", "couillon" has no exact english synonym. Closest I can imagine, in spirit, would be "bollocks-brained", or "nutcase" which also carries the anatomical undertone.

So, "un détrompe-couillon" could directly translate as "a foolproofer" - though that translation is tamer than the original for lack of testicles.

Re: Poka-Yoke

#47
post #10

"Anything that can go wrong, will go wrong" - Murphy "Dubble check that spelIng" - Muphry Murphy was a rocket engineer. One day their assistant plugged in a non-keyed connector upside down. It was very easy for that to go wrong. Another time, in another place, a rocket assembly worker hammered in a keyed connector - upside down. It was harder for that to go wrong, but, uh, life finds a way.

https://spacecraft.ssl.umd.edu/akins_laws.html

38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.

I've been thinking about this one lately - What do we want to do? What can we do?

43. You really understand something the third time you see it (or the first time you teach it.)

I'd like to say something like: any learning you do before you start working on something is just familiarization. You can read the book 10 times, but the real learning starts when you pick up the tools.

8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.

Ah, but the middle of WHAT? How to tell if your data is skewed?

18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.

https://quoteinvestigator.com/2018/11/28/possible/

> When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.

Stated otherwise:

    Youth desires growth. Maturity desires survival.

Re: Poka-Yoke

#48
post #8
post #3

I like collecting little ideas like this. Slightly meta-ironically I'd describe the genre as "just abstract enough to be useful nuggets of knowledge" and I have an org file full of them. The hard part is I don't know any better name for such "concepts" so I can't search for other people's lists. Does anyone else keep a similar collect or have advice for finding more? (For example Gurwinder sometimes posts lists like…

I have some bookmarked, but definitely not a nice list like that one, and not as many. Do you have more like these? I love to indulge into these for a few minutes a day, during commuting on the subway. I am always wondering if its because it somehow gives instant gratification into that desire to do something meaningful with the time with very little effort, ie that something new was learned (and then usually as inst…

Ok, I took a rough list I had on my phone and added LLM summaries: https://pastebin.com/crrkdYfb
Post reply on HN