Military standard on software control levels

A lot of people look at safety critical development standards to try and copy process bits for quality. In reality, 90% of the quality benefits come from sitting down to think about the software and its role in the overall system. You don't need all the fancy methodologies and expensive tools. It's also the main benefit you get from formal methods.

I've found that a quality process that starts with "you need to comprehensively understand what you're engineering" is almost universally a non-starter for anyone not already using these things. Putting together an exhaustive list of all the ways code interacts with the outside world is hard. If a few engineers actually manage it, they're rarely empowered to make meaningful decisions on whether the consequences of failures are acceptable or fix things if they're not.

i prefer the "criticality" categorization of Alistair Cockburn in his crystal clear methodologies.. [1] (funny, none of the hundreds of copycats includes that - it's only findable in the book itself (pp ~240):

""" A second important dimension is criticality, the potential damage caused by an undetected defect: loss of comfort (C), loss of discretionary moneys (D), loss of essential moneys (E), and loss of life (L). """

(my rephrasing): he points that the more one moves further into that list, the more hardened/disciplined the way of making should be. From "anything goes" in the beginning to "no exceptions whatsoever" in the end.

[1] https://www.researchgate.net/publication/234820806_Crystal_c...

To be honest, I’m not going to take advice from the guys who have to reboot their machines every 30 days or they won’t work.