Originally Posted by
MikeBanahan
Rather than assuming that all software is broken, or faulty or defective, it's smarter not to wag a finger in the direction of the software but instead to ask searching questions about HOW it was engineered from end to end and to what quality standards, just as you would with a mechanical component.
There is nothing unique about software. It's an engineered product like any other and can be produced to similar quality levels.
Nicely put, Mike.
I've been saying much the same thing on these forums for quite some time now. There's simply no comparison between the kind of software we use in homes and businesses - which until recently tended to be fairly free-form in design and loosely specified, and the kind of formally-specified and aggressively tested real-time software that goes into aviation use, among other safety-critical sectors.
That said, the kind of aggressive testing and integration management used in safety-critical systems from the get-go is starting to find its way into modern mainstream software development, and the take-up has been growing exponentially for the last decade or so. It's not dissimilar to how mechanical tech derived from aviation has been filtering into other uses (e.g. anti-lock braking systems on motor vehicles).
Originally Posted by
HighAndFlighty
I'm surprised that nobody has mentioned QF32. IIRC that little drama started out with a single (albeit uncontained) engine failure on a 380.
And yet in that incident the crew elected to stay in the air for an hour or two - despite their proximity to the airport - to work through the ECAM and thus discover which systems were still functioning. I recommend reading Captain De Crespigny's book on the subject - it makes for entertaining and fascinating reading.