Interesting read! I like how the final request foreshadows the creation of agile software development techniques. But as far as I know the shuttle software stay

Interesting read! I like how the final request foreshadows the creation of agile software development techniques. But as far as I know the shuttle software stayed with a classic linear development model (waterfall or V model?). Agile development is tough in embedded systems. Test automation only works up to a point. Integration and system testing turns into a monstrosity requiring hardware in the loop. And there are the inevitable failure modes that need to be caught reliably, but can only be simulated by modifying the hardware under test (I.e. manual testing). All of this means that no purely iterative model.is going to work. You must have discrete testing phases in your project. And in theory they need to be redone entirely before every iterative update that gets into production. Right now, testing efforts are reduced by doing impact analysis of the changes and reducing the scope of the tests to affected portions of the code. But this requires the impact analysis to be perfect and without omissions. This article nicely shows how an impact analysis can be wrong, causing major issues down the road from a simple change (a single, seemingly unrelated changed constant).