The Therac-25 disaster should be on this list: https://en.wikipedia.org/wiki/Therac-25
Software engineering lessons from RCAs of greatest disasters
81–90 of 150 posts
Re: Software engineering lessons from RCAs of greatest disasters
#82The Therac-25 disaster should be on this list: https://en.wikipedia.org/wiki/Therac-25
[deleted]
Re: Software engineering lessons from RCAs of greatest disasters
#83Earlier quoted context omitted.
Pretty epic. I was working for a webhosting company, and someone asked me to rush a change just before leaving. Instead of updating 1500 A records, I updated about 50k. Someone senior managed to turn off the cron though, so what I actually lost was the delta of changes between last backup and my SQL. I was in the room for this though: https://www.theregister.com/2008/08/28/flexiscale_outage/
I love the title to that article "Engineer accidentally deletes cloud". It's like a single individual managed to delete the monolithic cloud where everyone's files are stored.
That is eerily similar to what happened to us in IBM "Cloud", in a previous gig. An engineer was doing "account cleanup" and somehow our account got on the list and all our resources were blown away.
The most interesting conversation was convincing the support person, that those deletion audit events were in fact not us, but rather (according to the engineer's Linked-In page) an SRE at IBM.
Re: Software engineering lessons from RCAs of greatest disasters
#84One of my favourites that I ever heard about was from a friend of mine who used to work on safety-critical systems in defense applications. He told me fighter jets have a safety system that disables the weapons systems if a (weight) load is detected on the landing gear so that if the plane is on the ground and the pilot bumps the wrong button they don't accidentally blow up their own airbase[1]. So anyway when the Eu…
You would think "grep the codebase for FIXME" would be in the checklist before deployment.
Re: Software engineering lessons from RCAs of greatest disasters
#85One of my favourites that I ever heard about was from a friend of mine who used to work on safety-critical systems in defense applications. He told me fighter jets have a safety system that disables the weapons systems if a (weight) load is detected on the landing gear so that if the plane is on the ground and the pilot bumps the wrong button they don't accidentally blow up their own airbase[1]. So anyway when the Eu…
Yup, watch videos of actual missile launches--the missile descends below the plane that fired it. Can't do that on the ground, although you won't blow up your base because the weapon will not have armed by the time it goes splat.
Re: Software engineering lessons from RCAs of greatest disasters
#86Earlier quoted context omitted.
If you're making the same mistakes over and over again I think that says more about your company than it does about the software industry. My first job was at a major automotive manufacturer. Implementing half the procedures they had would slow down any software company 10X - just look at the state of most car infotainment systems. If something is safety critical, obviously this makes sense but the reality is 85% of…
GP was speaking in the general sense not about their company.
Is that not coming from experience of working at a software company? As I believe you said elsewhere
Re: Software engineering lessons from RCAs of greatest disasters
#87Re: Software engineering lessons from RCAs of greatest disasters
#88The Challenger disaster is on the list but should be expanded upon:
1) Considerable pressure from NASA to cover up the true sequence of events. They pushed the go button even when the engineers said no. And they failed to even tell Morton-Thiokol about the actual temperatures. NASA dismissed the observed temperatures as defective--never mind that in "correcting" them so the temperature at the failed joint was as expected meant that now a bunch of other measurements are above ambient. (The offending joint was being cooled by boiloff from the LOX tank that under the weather conditions at the time ended up cooling that part of the booster.)
2) Then they doubled down on the error with Columbia. They had multiple cases of tile damage from the ET insulating foam. They fixed the piece of foam that caused a near-disaster--but didn't fix the rest because it had never damaged the orbiter.
Very much a culture of painting over the rust.
Re: Software engineering lessons from RCAs of greatest disasters
#89One of my favourites that I ever heard about was from a friend of mine who used to work on safety-critical systems in defense applications. He told me fighter jets have a safety system that disables the weapons systems if a (weight) load is detected on the landing gear so that if the plane is on the ground and the pilot bumps the wrong button they don't accidentally blow up their own airbase[1]. So anyway when the Eu…
Torpedoes typically have an inertial switch which disarms them if they turn 180 degrees, so they don't accidentally hit their source. When a torpedo accidentally arms and activates on board a submarine (hot running) the emergency procedure is to immediately turn the sub around 180 degrees to disarm the torpedo.
Lest someone think this is purely hypothetical: https://en.wikipedia.org/wiki/USS_Tang_(SS-306)
Re: Software engineering lessons from RCAs of greatest disasters
#90One of my favourites that I ever heard about was from a friend of mine who used to work on safety-critical systems in defense applications. He told me fighter jets have a safety system that disables the weapons systems if a (weight) load is detected on the landing gear so that if the plane is on the ground and the pilot bumps the wrong button they don't accidentally blow up their own airbase[1]. So anyway when the Eu…
> this cost several millions to redeploy the (one-line) fix to actually check the weight from the sensor was less than the threshold Well maybe this is the other, compounding problem. Engineering complex machines with such a high cost of bugfix deployment seems like a big issue. It's funny that as an industry we now know how to safely deploy software updates to hundreds of millions of phones, with security checks, si…
>It's funny that as an industry we now know how to safely deploy software updates to hundreds of millions of phones, with security checks, signed firmwares, etc, but doing that on applications with a super high unit price tag seems out of reach
A bunch of JavaScript dudebros yeeting code out into the ether is not at all comparable to deploying avionics software to a fighter jet. Give your head a shake.