The system design failure in the A5 is interesting to read, the full report is at

http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html

Basically they tried to re-use software from the A4 in the A5. The laser gyros have firmware that can get funky and the onboard computer would kind of "trust but verify" the laser gyros on the A4. Obviously the programmers of the laser gyros and the programmers of the nav system are not the same people and had conflicting views on what makes a decent variable type for horizontal velocity. The A5 doesn't technically need to verify the lasers alignment and its of no use after liftoff anyway (so whaddya intend to do if it gets misaligned anyway, land, fix it, and take off again?) The A4 guys saw that pointlessness of it and stopped monitoring after 40 or so seconds (by then either its working great or you've already crashed...)

So the A4 being somewhat anemic never hit the limits of that size int for horiz velocity. But the A5 which was kind of like the A4 after extensive steroids use was able to max out or roll over the conversion routine.

The nav computer wasn't very well designed at yet another level and instead of going all RTOS and recovering in a few milliseconds it helpfully kernel panic'd. And the kernel panic error message (probably something like "Oh oh" in French) was helpfully interpreted by the engine computer as if it were commands and slammed the engine nozzles over full hard one direction, which the airframe couldn't survive (real big rockets can't pinwheel in flight, at least not in one piece)

So the list of software design failures is epic and huge

1) Not every minor math exception NaN should kernel panic and fail the whole system (shouldn't have to crash because one temp sensor got unplugged, etc)

2) Never do stuff you don't have to. If you don't need to align your lasers due to technological advances, then stop doing it, because you can't crash the whole system trying to do it if you never try to do it. Or, if, 50 seconds into flight, you're commanded to slam your engine nozzles to 90 degrees perpendicular to flight and you know the hardware can't bend that far anyway, I think you can safely assume the nav computer has crashed and ignore it for awhile (maybe the watchdog timer would have eventually saved them?), or rephrased if you're commanded to do something that'll certainly blow the ship up, unless you're a destruct charge, maybe you should ignore it and just keep on chugging along till you hear something saner.

3) Most epic system failures are at the border of subsystems. Like where one machine talks 16 bit ints and the other 64 bit floats. So minimize your borders.

4) Simulation could have saved half a billion bucks. I'm actually kinda surprised nobody ever tried this. I guess test driven development wasn't so cool back then.

One way to look at the design failure is numerous times they failed when when handling protocol failures. I've seen this in big bureaucracies time and time again, who cares if the overall mission fails as long as our little group did right by our own code and someone else can be blamed. The nav guys never should have asked us laser gyro guys our horiz speed if it was over 15 bits signed so its all their fault for asking. The nav guys never should have asked us engine computer guys to point my engine nozzle sideways thus snapping off the back of the rocket so its all their fault. The OS guys never should have asked us math coprocessor guys to convert -40000.123 m/s into a 16 bit int so its all their fault. The math guys should never have thrown a kernel panic on a mere numerical conversion crashing the OS so its all their fault not ours in OS land. The OS guys should never have run our nav routines on a survivable recoverable non-RTOS system so its all their fault. Management never let us software devs run a ground test to save money so its all their fault. The blamestorming could go on for pages.