Live data from Hacker News

Software engineering lessons from RCAs of greatest disasters

anoopdixith.com

11–20 of 150 posts

Re: Software engineering lessons from RCAs of greatest disasters

#11
I think the software industry itself has accumulated enough bugs over the past few decades. E.g.

F-22 navigation system core dumps when crossing the international date line: https://medium.com/alfonsofuggetta-it/software-bug-halts-f-2...

Loss of Mars probe due to metric-imperial conversion error

I've a few of these myself (e.g. a misplaced decimal that made $12mil into $120mil), but sadly cannot devulge details.

Re: Software engineering lessons from RCAs of greatest disasters

#12

(Root Cause Analysis)

This whole RCA terminology has to die. The idea that there exists a single "Root Cause" that causes major disasters is fundamentally flawed.

If we call it Root Causes Analysis can we keep the acronym?

Re: Software engineering lessons from RCAs of greatest disasters

#13
post #4

I don't think this list hits any fundamental truths. The great depression doesn't have parallels to software failures beyond the fact that complex systems fail. And many of the lessons are vague and unactionable - "Put an end to information hoarding within orgs/teams" for example, says nothing. The Atlassian copy that section links to also says nothing. A lot of the lessons lack meaty learnings, and good luck to anyo…

Complex systems fail, but they don't all fail in the same way and analyzing how they fail can help in engineering new and hopefully more robust complex systems. I'm a huge fan of Risk Digest and there isn't a disaster small enough that we can't learn from it.

Obviously the larger the disaster the more complex the failure and the harder to analyze the root cause. But one interesting takeaway for me from this list is that all of them were preventable and in all but few of the cases the root cause may have been the trigger but the setup of the environment is what allowed the fault to escalate in the way that it did. In a resilient system faults happen as well, but they do not propagate.

And that's the big secret to designing reliable systems.

Re: Software engineering lessons from RCAs of greatest disasters

#14

(Root Cause Analysis)

This whole RCA terminology has to die. The idea that there exists a single "Root Cause" that causes major disasters is fundamentally flawed.

Yes, that's true in the general sense. But root causes are interesting because they are the things that can lead to insights that can help the lowest levels of engineering to become more robust. But at a higher level it is all about systems and the way parts of those systems interact, fault tolerance (massively important) and ensuring faults do not propagate beyond the systems they originate in. That's what can turn a small problem into a huge disaster. And without knowing the root cause you won't be able to track those proximate causes and do something about it. So RCA is a process, not a way to identify the single culprit. So this is more about the interpretation of the term RCA than about what RCA really does.

Re: Software engineering lessons from RCAs of greatest disasters

#15
post #11

I think the software industry itself has accumulated enough bugs over the past few decades. E.g. F-22 navigation system core dumps when crossing the international date line: https://medium.com/alfonsofuggetta-it/software-bug-halts-f-2... Loss of Mars probe due to metric-imperial conversion error I've a few of these myself (e.g. a misplaced decimal that made $12mil into $120mil), but sadly cannot devulge details.

My worst bug was a typo in a single line of html that removed 3DS protection from many millions of dollars of credit card payments

Re: Software engineering lessons from RCAs of greatest disasters

#16
post #7

Earlier quoted context omitted.

This whole RCA terminology has to die. The idea that there exists a single "Root Cause" that causes major disasters is fundamentally flawed.

Actually everywhere "defense in depth" is used (not only in computing, but also in e.g. aviation), there can't be one single cause for a disaster - each of the layers has to fail for a disaster to happen.

Almost every accident, even where there is no defense in depth has more than one cause. Car accident: person A was on the phone, person B didn't spot their deviation in time to do anything about it: accident. A is the root cause. If B would have reacted faster then there wouldn't be an accident but there would still be cause for concern and there would still be a culprit. The number of such near misses and saves by others is similar to the defense in depth in effect even if it wasn't engineered in. But person B isn't liable even though their lack of attention to what was going on is a contributory factor. So root causes matter, that's the first and most clear thing to fix. Other layers may be impacted and may require work but that isn't always the case.

In software the root cause is often a very simple one: assumption didn't hold.

Re: Software engineering lessons from RCAs of greatest disasters

#17
post #15
post #11

I think the software industry itself has accumulated enough bugs over the past few decades. E.g. F-22 navigation system core dumps when crossing the international date line: https://medium.com/alfonsofuggetta-it/software-bug-halts-f-2... Loss of Mars probe due to metric-imperial conversion error I've a few of these myself (e.g. a misplaced decimal that made $12mil into $120mil), but sadly cannot devulge details.

My worst bug was a typo in a single line of html that removed 3DS protection from many millions of dollars of credit card payments

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/

Re: Software engineering lessons from RCAs of greatest disasters

#18
post #6

Another train crash that holds a valuable lesson was https://en.wikipedia.org/wiki/Eschede_train_disaster This demonstrates that sometimes "if you see something, say something" isn't enough - if a large piece of metal penetrates into the passenger compartment of a train from underneath, it's better to take the initiative and pull the emergency brake yourself .

Not entirely true:

> Dittmann could not find an emergency brake in the corridor and had not noticed that there was an emergency brake handle in his own compartment.

The learning from that should maybe instead be to keep non-technical management out of engineering decisions. The Wikipedia article fails to mention there was a specific manager who pushed the new wheel design into production and then went on to have a long successful career.

Re: Software engineering lessons from RCAs of greatest disasters

#19
post #15
post #11

I think the software industry itself has accumulated enough bugs over the past few decades. E.g. F-22 navigation system core dumps when crossing the international date line: https://medium.com/alfonsofuggetta-it/software-bug-halts-f-2... Loss of Mars probe due to metric-imperial conversion error I've a few of these myself (e.g. a misplaced decimal that made $12mil into $120mil), but sadly cannot devulge details.

My worst bug was a typo in a single line of html that removed 3DS protection from many millions of dollars of credit card payments

I posted this, in case we want to collect these gems: https://news.ycombinator.com/item?id=37160295

Re: Software engineering lessons from RCAs of greatest disasters

#20
post #11

I think the software industry itself has accumulated enough bugs over the past few decades. E.g. F-22 navigation system core dumps when crossing the international date line: https://medium.com/alfonsofuggetta-it/software-bug-halts-f-2... Loss of Mars probe due to metric-imperial conversion error I've a few of these myself (e.g. a misplaced decimal that made $12mil into $120mil), but sadly cannot devulge details.

my funniest was a wrong param in a template generator which turned off escaping parameter values provided indirectly by the users. good that it was discovered during the yearly pen testing analysis because it lead to shell execution in the cloud environment.
Post reply on HN