Abstracting out of planes to software on general - this is what happens when your testing surface dramatically expands. You can have a product that has been wo

Abstracting out of planes to software on general - this is what happens when your testing surface dramatically expands. You can have a product that has been working just fine, generally, but when you start adding tests for new situations, you can suddenly get a LOT more tests....with most of them failing. TDD advocates (and I'm a fan) will be feeling smug, be that doesnt apply here - the issue is not the initial tests, but explicitly tests after the fact, on criteria that werent in the initial tests. Be it by oversight or deliberate choice, TDD is in the same boat here. All of which underlines how hard complex software can be. Boeing made lots of mistakes, and many of us might recall happier examples from our past (new criteria, but a well-written suite passes it all with minimal effort), but such examples are selection bias - if we exclude the code we know is a mess, the remaining mix of did-well and did-poorly code looked GOOD before. (Here I'm generalizing from my experience and the war stories I've heard) Which brings us back to the Waterfall vs Agile issue. We know that we generally stink at anticipating all the requirements. We also know that the better we do at anticipating those requirements the less likely we are to have a sudden spec change derail us (not because we can prevent the spec change, but because our code tends to work) Anyone asserting that such problems are simple to resolve hasn't worked on enough such problems. We are learning, but this field is still in its infancy and we've not even finished understanding some of the earliest principles the pioneers in the industry laid out.