Hacker News Reader

Comment by nmstoker | Hacker News Reader

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

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.

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...

> 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.

Maybe something like throwing an exception when updating a collection that is being enumerated over.

Or perhaps the constructor pattern requiring object construction to complete before a reference to the object is available.

Reply on news.ycombinator.com