Wait, ARE TYPESYTEMS POKA-YOKE FOR PROGRAMMING?!?!?!<p>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.
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).<p>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.<p>The system was complex and costly to build, but less costly than a single mistake like the one that inspired it.
Poka-yoke is a massively useful concept in the design of physical objects, and it should apply to design of software interfaces as well.<p>A key principle is making different things <i>look</i> 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.
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.<p>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.<p>Most of the times I try to include some sort of testing, or alternatively generate index files about the dependencies needed to build.<p>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...
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.