The auto system failed because they a) were band-aiding a flawed mechanical design b) under-designed the compensating software (only provided a single AOA sensor by default) to obscure the fact the plane was significantly different to avoid training costs. These are management problems, not technical problems. More automation would be subject to the same issues.
Crap I meant to make the above comment as a top level comment, not a response.. Somehow it came through twice.
Anyway, in response to your comment: perhaps I'm conflating these, but a commitment to robustness seems like it's included in the newer philosophy? It just extends that notion beyond the sensor-level to the system level.
Sure, you can frame an inadequate emphasis on robustness as a "management problem" instead of a technical one, but that seems equally applicable to the "management solution" being put forth, no?
I would say that framing a business problem in engineering terms will lead to an unclear understanding of the problem. The executives were attempting to thread the needle of a potentially business killing competition with Airbus and were willing to make compromises to safety to save their skins. No engineering methodology can save you from motivated reasoning and systems level problems like that because management will force exceptions to whatever process is in place.
The only thing that would be an appropriate counterweight is if the engineering staff refuses to put a defective design into production. A robust engineering process can make violations and exceptions clear, but if the staff still does what management says, it won't help.
