alt Hacker NewsA 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.
Replies
Another good document for military standards for software safety is AOP-52.
Has some fun anecdotes in it. My favorite being the nuclear certified supersonic aircraft having a latent defect discovered during integration of a new subsystem. Turns out all of the onboard flight computers crashed at the transition from sub to supersonic, thankfully the aircraft had enough inertia to "ride through" all of their flight computers simultaneously crashing during the transonic boundary.
Moral of that story is your software people need to have the vocabulary to understand the physical properties of the system they're working on.
I also generally find that people looking for “best practices” to follow are trying to avoid that “sitting down to think about the software and its role in the overall system” piece.
Absolutely. If you look at an extensively used standard like DO-178C for avionics, it really says very little about how to program. Instead, the emphasis is on making sure that the software has implemented system level requirements correctly.
I see the fancy methodologies and processes as the way of streamlining what you have to do in order to "sit down to think about the software", particularly in teams of more than one developer.
Most of it happens, as always, at the interface. So these methodologies help you manage these interfaces between people, machine and product.
>Putting together an exhaustive list of all the ways code interacts with the outside world is hard.
Maintaining it over time is even harder.
I think the main benefit of these standards is that when someone proposes a project, the level gets evaluated and either enough (and appropriate) resources are allocated or it is killed in an ideal world.
it's cargo culting. we see the same thing with "agile", which is often used as an excuse to just do what they were going to do anyway.
they want the benefits, and are willing to do everything except the things that actually help.
It doesn't help that many of the popular methodologies focus entirely on failures. They ask a bunch of questions in the style of "how likely is it that this part fails?" "what happens if it fails?" "how can we reduce the risk of it failing?" etc. But software never fails[1] so that's the wrong approach to start from!
Much better to do as you say and think about the software and its role in the system. There are more and less formal ways to do this, but it's definitely better than taking a component view.