The problem with software is that if you have code to deal with unusual situations (like unusual drag on one wing), that code might not ever get exercised in real life until something goes somewhat wrong.
And if there's a bug in that section of code, it may turn a "somewhat wrong" situation into a "catastrophicly wrong" situation. I would take a good hard look at the possibility that unusual drag (or loss/corruption of sensor input) may have caused the computer to overcorrect at Mach 20 (with disasterous results).
Your code setpoints should not allow for an overcorrection.
And if there's a bug in that section of code, it may turn a "somewhat wrong" situation into a "catastrophicly wrong" situation. I would take a good hard look at the possibility that unusual drag (or loss/corruption of sensor input) may have caused the computer to overcorrect at Mach 20 (with disasterous results).
Very well said. I'm a programmer, and we've had applications out in the field which suddenly turned up nasty bugs after over a DECADE of proper operation, due to what we jokingly call "the moon is full and it's a tuesday on a leap year" bugs.
These are the ones that only manifest themselves when a rare set of circumstances combine.
I can easily see something like that happening in the Columbia disaster -- a bug or poor design decision in an ancient piece of code which never rose itself from slumber until the very first time a high-drag-on-the-left situation ever occurred.
I was thinking along the same lines. Although the first time I got there was thinking about deliberate "bug" in the code. I wonder if they did a new build of the code prior to this mission, or if conditions with the heavier bird, were just enough different to trigger the "bug"?