4 ms·

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

koolhaas 5y ago
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.
nerdponx 5y ago
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.
- wheelinsupial 5y ago
  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_RiskManagement.pdf 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/videos/reliability-and-safety/ 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 http://www.softrel.com/fmea%20overview.pdf https://swehb.nasa.gov/display/SWEHBVC/8.5+-+SW+Failure+Modes+and+Effects+Analysis?desktop=true&macroName=show-if https://swehb.nasa.gov/display/SWEHBVC/8.5+-+SW+Failure+Mode... https://www.witpress.com/Secure/elibrary/papers/SQM95/SQM95019FU.pdf https://www.witpress.com/Secure/elibrary/papers/SQM95/SQM950... Automotive / manufacturing: http://www.phf.org/resourcestools/Documents/Mistake_Proofing.pdf http://www.phf.org/resourcestools/Documents/Mistake_Proofing... https://www.aiag.org/event-presentations/S16QUALITY/ERROR_final.pdf https://www.aiag.org/event-presentations/S16QUALITY/ERROR_fi...
  - toast0 5y ago
    > 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?
selfhoster11 5y ago
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.
jayd16 5y ago
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.

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.

nerdponx 5y ago

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.

wheelinsupial 5y ago
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_RiskManagement.pdf 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/videos/reliability-and-safety/ 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 http://www.softrel.com/fmea%20overview.pdf https://swehb.nasa.gov/display/SWEHBVC/8.5+-+SW+Failure+Modes+and+Effects+Analysis?desktop=true&macroName=show-if https://swehb.nasa.gov/display/SWEHBVC/8.5+-+SW+Failure+Mode... https://www.witpress.com/Secure/elibrary/papers/SQM95/SQM95019FU.pdf https://www.witpress.com/Secure/elibrary/papers/SQM95/SQM950... Automotive / manufacturing: http://www.phf.org/resourcestools/Documents/Mistake_Proofing.pdf http://www.phf.org/resourcestools/Documents/Mistake_Proofing... https://www.aiag.org/event-presentations/S16QUALITY/ERROR_final.pdf https://www.aiag.org/event-presentations/S16QUALITY/ERROR_fi...
- toast0 5y ago
  > 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?

selfhoster11 5y ago

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.

jayd16 5y ago

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.