My takeaway from reading the fastcompany.com article is that it's not process improvement per se that provides quality software, it's money. NASA has invested a great deal more time, and therefore money, into developing software than a typical commercial software company can afford. We will need quite a lot more programmers necessarily getting paid a lot less if we want commercially viable software production within spitting distance of NASA quality expectations.

That's just it. If a bug in software can cause death you're not going to use agile. You're going to use a waterfall-like process, and you're going to have stringent quality gates at every single transition - from envisioning, through requirements analysis, design, development, test, release, and into operation. It's the only way. I know because I built a military guaranteed messaging system. Tech aspect was small, but it took 24 months.

Then again, agile has some relation to lean (which of course is a production method, not a design method) - and cars probably have a much higher chance of killing people than space craft do.

I think it is more a case of "what you can get away with" in terms of domain knowledge and risk: If there's only some money on the line - taking a hit from time to time from bugs, bad design etc - will often be cheaper than slowing down the design and production process. Especially if a system with (some) bugs can start earning money on day X, while a "perfect" system would require some N > X days more to start earning money.

Waterfall is a perfectly valid process - but for it to work, it puts a very high demand on the domain knowledge of those involved, as well as information management. And in reality I think very, very few large projects get away with no iterations for sub-modules.

I was working with a crew that was refurbishing deep sea drilling platforms - originally built in the 70s. One particular task was moving anchor winch engines, along with ventilation (vent-hole had to be displaced due to moving the engine(s)). On the design the crew got from engineering, the hole was just moved some 10 meters. But the engineer was clearly working from out-dated drawings - moving the hole as indicated would have lead the team to cut through half of a fuse board, some computer controls for some other sub-system and through an interior supporting strut. In the end the solution turned out to be prototyping a longer shaft with pvc pipe, and then welding the thing in place, in pieces. The one-day job turned into a two week job - so the cost of the single mistake on a drawing cost an enormous amount of money (but of course, there were many such mistakes, so who knows how early the rig could've been out of dock anyway...). On the other hand, it got fixed.

I absolutely agree that you need more than "just agile", though. You need (a probably multi-stage) verification process, for example. In the example above, the welding and angle of the pipe was inspected first by the crew leader, and later by external inspectors -- that particular system didn't directly affect life or death, but as it was venting from from propulsion engines (I think) - an error leading to rust or system suspension would be very costly.

Unit tests do not even prove that unit functions correctly either. Code coverage doesn't necessarily mean anything too.