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.
Another great Firefox example is the shortcut for "close all the tabs" (ctrl+shift+q), which also happens to be adjacent to "go to previous tab" (ctrl+shift+tab). Depending on your preferences, there won't even be a warning popup if you accidentally press it.
I accidentally clicked "Forget about this site" on an item with google domain in Firefox history recently. Cue 5-minute freeze and having to re-login, not to mention losing the entire browser-local googling history.
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).
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.
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.
And notably, as a kinda higher-level challenge towards poka-yoke...:
The improper installation apparently required some considerable physical effort, which, somehow did not raise any alarm at GKNPTs Khrunichev's assembly plant in Moscow. (...) By July 13, investigators simulated the improper installation of the DUS angular velocity sensors on the actual hardware. As it turned out, it would be very difficult to do but not impossible. To achieve that personnel would need to use procedures and instruments not certified either by the design documentation or the installation instructions. As a result, the plate holding the sensors sustained damage. Yet, when the hardware recovered from the accident was delivered to GKNPTs Khrunichev, it was discovered that the nature of the damage to the plate had almost exactly matched the simulated version.
(To make it clear, I absolutely love the idea of poka-yoke, and find it great help in software development as well; still, I find the story both hilarious and educative ;) )
Another (smaller) example is the detachable controllers on the Nintendo Switch ("Joy-Con") which are very hard to remove if you accidentally reattach them upside down.
I think one implementation if this is where Japanese rail workers point and call out the thing they are noting, checking, or changing as a form of conscious attention.
That's more of a learned behavior that helps you consciously check everything; it's almost the opposite of pokayoke. Implementing pokayoke would involve locking out (or making it incredibly hard) for rail workers to continue a process without confirming that everything has been done as intended.
Maybe. I think it wouldn't qualify for a few reasons. I'm sure others would be able to justify this as being a form of error proofing.
1. From Toyota Production System An Integrated Approach to Just-In-Time by Yasuhiro Monden, "A mistake-proofing system consists of a detecting instrument, a restricting tool, and a signaling device. The detecting instrument senses abnormalities or deviations in the workpiece or the process, the restricting tool stops the line, and the signaling device sounds a buzzer or lights a lamp to attract the worker's attention." I don't think pointing and calling works for this since there is a human in the loop that would have to detect, for example, the speed is too fast for the segment of track, restrict the speed by slowing the train down, and call attention to another operator to help. The goal is to eliminate the human from this process to ideally free them up to do work that respects their humanity [1].
2. Pointing and calling is only 85% effective as called out on the Wikipedia page for it. The benefit of mistake proofing is 100% built-in quality control according to the Wikipedia page.
3. From practical experience in automotive part manufacturing, our customers did not accept human based interventions or process changes as a form of error proofing. The error proofing needs to be built into the process and it can't be something that an operator can by pass. Pointing and signalling can be bypassed if the employee chooses not to do it. I'm sure there is ways of bypassing some error proofing systems, but that's what the customer wants.
Error proofing is part of a system called autonomation []. One of the goals is to be able to have multi-skilled workers be able to work within a cell. Basically the human operator takes on a loading and unloading focus in the manufacturing process. Several operations would be performed in sequence. The operator would put the raw material in at one side of a machine cell, transfer it to the subsequent operations until the last operation has been completed. The goal is for the piece to be produced with minimal waiting time between each successive operation and for the machines to be able to detect if a defect has been produced.
A related term for this from the Jargon File is the "molly-guard"
> molly-guard: n.
> [University of Illinois] A shield to prevent tripping of some Big Red Switch by clumsy or ignorant hands. Originally used of the plexiglass covers improvised for the BRS on an IBM 4341 after a programmer's toddler daughter (named Molly) frobbed it twice in one day. Later generalized to covers over stop/reset switches on disk drives and networking equipment. In hardware catalogues, you'll see the much less interesting description “guarded button".
There is a Debian package with the same name that does the same thing: replaces shutdown and reboot scripts with ones that need an additional confirmation before you bring the machine down.
When writing and running SQL one-offs interactively, I will surround it with `if 1<>1 begin end` or comments, or add syntax errors at the top so that I won't accidentally run it without first selecting the part I want to run. I should get into the habit of writing `begin; rollback` instead for extra-safety.
And I always write the WHERE clause before the DELETE or UPDATE keywords.
> And I always write the WHERE clause before the DELETE or UPDATE keywords.
I sometimes get nervous typing 'rm -r' commands, since it starts with a very broad path, and only narrows-down as we type more, e.g. if we hit enter prematurely when typing 'rm -r ~/Downloads/archive.zip' we might delete our entire home directory, or all of our downloads.
For this reason I often prefix dangerous steps with 'echo'; once I'm confident it's correct, I'll then run the script and double-check that variables/flags/etc. expanded as expected; and only then will I remove the echoes.
Similarly, i sometimes start writing the command line with 'ls' or 'find', and then run it, and once i'm satisfied it describes the right things, i change the find to an rm.
One reason for having the flags before the <path> is so that you can terminate the flags by using '--'. This is especially useful to prevent dubious files being expanded that might start with '-' and be interpreted as flags that leads to unexpected results.
Note that my Debian's `rm` happily supports terminating flags using `--` when necessary, so wanting to support `--` syntax doesn't have to come at the expense of writing -r last.
Almost always, if I'm inputting `rm` manually in a shell, I don't need `--`; very few filenames on my disk start with -.
Quite a lot of SQL dialects allow the syntax "DELETE * FROM X" for this exact reason, allowing you to more easily change a select statement into a delete.
The above solution unfortunately doesn't work for those of us who use fzf (or other fuzzy runners), since that RUN_SCARY_THINGY=yes var will be part of the matched line which you will run inadvertently in your coffee-deprived mind.
I rarely make mistakes while consciously typing out commands, but running commands with wrong arguments because I didn't pay enough attention on the matched line does happen semi-regularly.
Doesn't help that since doing stuff with fzf is much faster than typing out full commands, that your brain sometimes just doesn't have enough time to ask -- wait, should I be running this right now?
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.
That seems a bit unfair since it literally comes from the direct translation of 'idiot proof'.
It's true that you can benefit from idiot-proof design without being an idiot, but I would argue that you could market a microwave that doesn't turn off when you open the door, plastered with warnings and maybe a mandatory course on how to operate it. An idiot-proof version would have safeguards that everyone could benefit from, but then saying that it's a fundamentally different concept just seems needlessly combative.
Fun fact: the microwave door switch does not only switch the thing off, it also shorts the power line. If the switch contact were melted and fused together unable to disconnect, it pops the breaker.
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
Arguably a (valve-based) pumping system without valves wouldn't be considered error-prone but rather non-functional? (I might be missing something, though, since I don't really know whether heart valves are dual-purpose like that.)
Why do you find it annoying? Electrical safety norms require either a ground pin attached to the shell or double insulation, and the charger has double insulation.
Moreover the Europlug has only two pins and fits every socket in Continental Europe, grounded plugs differ by country.
> Why do you find it annoying? Electrical safety norms require either a ground pin attached to the shell or double insulation, and the charger has double insulation.
Though totally safe, the leakage current I feel when touching the metal body is very annoying. See also here: [0]
> Moreover the Europlug has only two pins and fits every socket in Continental Europe, grounded plugs differ by country.
That is correct, hence why the plug in an Apple charger brick is interchangeable. However, the cable attachment is grounded, but the short attachment isn't. When using the cable attachment, the device is grounded and doesn't shock me, with the short attachment I get shocked.
Since they did make the grounded cable that fits my countries outlet, it annoys me that I can't get a short grounded attachment with the same plug.
It can apply anywhere. For software, there are packages for servers that replace the standard shutdown/reboot commands with something that prompts for confirmation first, or in the case of e. g. GitHub, you must type out the full name of the repo you're trying to delete to ensure that you're not deleting the wrong one.
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 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 my ~ 20 year career, I hardly ever got a real specification for what should happen when things went right. It was very hard to get people to even acknowledge that things could go wrong, let alone specify what should happen in that case. Almost always, they'd suggest something should never go wrong, or we should fix whatever it was that was going wrong, etc. Which sure, that'd be nice, but really everything breaks, so what do you want me to do when it does?
Sure, some Linux distros (or is it MacOS?) ask for confirmation before executing `rm -rf /`, which breaks the typical UX of the command but prevents bad mistakes.
These kind of electric paper cutters are common in Japanese school copy rooms. As they could easily cut fingers off, they require you to close the top cover and then both hands to operate the cut switches. (only after you've turned a big red arming switch)
https://nihonkiki.com/products/detail.php?product_id=4993
Common on industrial stamping presses also. Operator loads metal sheet, then needs to activate the press with two physical buttons, separated with enough distance that it can only be done with two hands.
Katakana sometimes is used to draw attention to words that would be normally written in hiragana or kanji. It can sort of function like italics or bold type that way.
In this case it might be used to signify that it is a specific method rather than just a collection of words. The english equivalent might be capitalizing the letters in Six Sigma to refer to a specific industrial quality process rather than the math term.
Contagion is the spreading of some property from one entity to another by come form of contact.
For instance "floating-point contagion" in computing which refers to a situation when an exact number and inexact number are combined together in on operation, and the exact number is first coerced to inexact. E.g. 0.5 + 1 is carried out as 0.5 + 1.0: the integer 1 value becomes 1.0.
> some automatic transmissions require the brake pedal to be depressed [to start]
Hmm, I was always told to do so when I was learning to drive. At some point I stopped doing so and it’s never been an issue, should I be stepping on the brakes when starting my car?
If it’s a push button ignition you have to, so almost all new vehicles. On keyed automatics, no. There are VERY few cars on the road that would start in drive or reverse or low. This is an old warning.
Manuals on the other hand, again, almost all have a clutch interlock to start, but a lot of trucks and jeeps can have clutch defeats and will move when the starter is hit while parked in gear. It’s pretty dumb, but there are tiny scenarios off road you might want that. Most people just don’t want to press the clutch to start for some reason. In many of these vehicles it’s as simple as pulling a fuse.
For safety, yes. This prevents the car from lurching forward (or backward) if you start it thinking the transmission is in park/neutral, when it is actually in gear.
Most modern cars have a lockout, preventing you from starting the engine unless the brake (or clutch) is pressed. However, some older cars do not have this feature.
Automotive EE here… I don’t think this is correct. If you are talking pre-electronic shift, your transmission still has position sensors and the engine or trans control module will not allow start while engaged. All vehicles have interlocks for this. Post electronic shift, it’s no question at all. You would need at least two errors in two completely separate circuits to get the vehicle to start in gear. Believe it or not, we think about these things.
For very very old transmissions, it’s probably possible to get this error, but nothing after 1995-1997.
I may be misunderstanding what you're saying, but many modern cars I've driven will still allow themselves to be started in gear.
It happened to me quite frequently until I built up the muscle memory for always starting with the clutch in, and occasionally still does if I forget (I drive a lot of hire cars).
But... If you are talking mtx (manual), which ones?
Because in 20 years of this industry I've never seen anything that didn't ship with a clutch interlock. So unless we're going back to pre-1997 - OR - you are in an "export market" like Asia, I am not aware of the models you're thinking of.
I'm not sure what an "export market" is, but I'm in the UK. Our cars seemed to have fewer automatic features for longer than other markets, for example cruise control was fairly rare until quite recently. I don't think I encountered a clutch interlock until 2015-ish (except on motorbikes) - I thought the car was broken.
I don't remember models specifically because I drive a different car each time, but I only got my driving license in 2007 and have had had the lurch happen as recently as last month (of course I have the handbrake on so it doesn't actually lurch, just stall). It might have been a VW T6 or a Vauxhall Vivaro, no more than a couple years old.
Certainly my mum's 2004 Daihatsu and my sister's 2008 Renault didn't have a clutch interlock. It's by far the exception that I need to engage the clutch before starter in all cases, but it could be in some cases that they would only require the clutch when also in gear.
Cars here still often fundamentally work similar to my first car (1998 Escort). Manual turn key ignition, able to start the engine by disengaging the clutch at speed, possible to stall at speed, put it into neutral then then restart the engine while driving, etc.
Mainly it's when driving hybrids that they seem a lot stricter.
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.