Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Complex Systems Fail (1998)

how.complexsystems.fail

Post reply on HN
Print view View original

81–90 of 90 posts

Re: How Complex Systems Fail (1998)

#81

Post by ErroneousBosh »

adrianN wrote: post #74
ErroneousBosh wrote: post #41

Earlier quoted context omitted.

My Grug-brained hill to die on is that there are many pieces of technology like the LM741 opamp, the Rover V8, Morris A-series and Peugeot XUD engines, and a big SQL database running on a thumping great Unix box, that have remained essentially unchanged for decades, worked well when they were new, and are still a perfectly good solution today for so much of what you want to do. You know what they have in common? A la…

I find it amusing that you classify a SQL database running on a Unix box as simple and unchanged in decades. Databases are some of the most complex pieces of software we regularly use and subject to highly active research. The operating systems running them and the hardware running those of course too.

From the point of view of you the database user, you the guy that sets up the database, that creates the SQL, that does "sudo apt install postgres", it's simple.

Could you repair the little Briggs and Stratton in your lawnmower? Almost certainly. You can easily hold a mental model of how it all works in your mind, and diagnose and repair any fault.

Could you actually design such an engine? Where would you start?

Re: How Complex Systems Fail (1998)

#83

Post by marcosdumay »

pdonis wrote: post #50
marcosdumay wrote: post #48

Earlier quoted context omitted.

> it’s a bit more straightforward in manufacturing That's because manufacturing is a simpler environment where causes and consequences are more conceptually distinct. Until you start to pull management decisions into your analysis, of course. Then it becomes just as complex as software.

> Until you start to pull management decisions into your analysis, of course. Meaning, having something like "management will decide not to fund maintenance for this component in the future, causing a failure" in your fault tree?

Yes, and "why did managenent decide not to do it?" too.

Re: How Complex Systems Fail (1998)

#85

Post by robwwilliams »

_boffin_ wrote: post #69
robwwilliams wrote: post #66

Earlier quoted context omitted.

Two other great books on failures in inevitably complex military operations are: 1. Command in War (1985) by Martin van Creveldt. He dissects may complex but common military failure causes up to the Vietnam War. 2. Team of Teams (2015) by Stanley McChrystal that is focused on what he and teams learned in Iraq but extrapolating to most organizations.

Did love Team of Teams. Need to check out the other

van Creveld is correct spelling.

Re: How Complex Systems Fail (1998)

#86

Post by esafak »

tptacek wrote: post #62
esafak wrote: post #51

Earlier quoted context omitted.

My response would be to use more sophisticated anomaly detection.

Problems managing a complex system? Why not consider adding another complex system!

You could simplify it some more and get rid of the checks altogether!

The right level of complexity is the minimum needed to get the job done, and if your existing anomaly detector isn't cutting it...

Re: How Complex Systems Fail (1998)

#87

Post by majormajor »

jonahx wrote: post #44
jasode wrote: post #38

Earlier quoted context omitted.

>The most commonly cited subtext or thrust of it is that "root cause analysis", at least on complex systems, is a fools errand. It's only an issue when people take that phrase very literally. People have common sense to understand that things have multiple causes and a chain of events. NASA has "Root Cause Analysis" (singular) all over various official documentation and it doesn't stop them from understanding that th…

> Another cause was the unrealistic flight schedules which can subconsciously pressure management into normalizing dangerous deviations. In the case of Challenger, I think it's pretty clear this was the "root cause": > According to testimony by Kilminster and Boisjoly, Mason finally turned to Bob Lund and said, "Take off your engineering hat and put on your management hat." Joe Kilminster wrote out the new recommenda…

A deeper cause there, as I understand it, is that the statistical analysis was incomplete/flawed but in a way that none of the technical practitioners caught and called out at the time. The way the data was presented was to the effect of "half of the o-ring damage incidents were in cold temp launches", which made things seem less bad. The way it could have been presented was more like "nearly every cold temp launch has resulted in damage, only like 10% of others do" (I forget the exact numbers) which is far more effective highlighting the impact of the temperature and the magnitude of the increased risk. And that would've let people make a stronger case "hey, we know temps in the 50s cause damage almost every time, and it's way colder today."

There's a "system" aspect (outside of power structures and incentives) which is that prob/stats knowledge among almost all engineering disciplines (industrial engineering waves from the sidelines) is exceedingly poor and often viewed as "soft" and "less important" than calculus, linear algebra, etc. And so practitioners are ill-equipped at spotting things like that ("wait, is this the right denominator? what about frequency of incident?").

Re: How Complex Systems Fail (1998)

#88

Post by [deleted] »

esafak wrote: post #86
tptacek wrote: post #62

Earlier quoted context omitted.

Problems managing a complex system? Why not consider adding another complex system!

You could simplify it some more and get rid of the checks altogether! The right level of complexity is the minimum needed to get the job done, and if your existing anomaly detector isn't cutting it...

[deleted]

Re: How Complex Systems Fail (1998)

#89

Post by Vinnl »

lstodd wrote: post #52
Vinnl wrote: post #30

Earlier quoted context omitted.

I feel like painfully falling without breaking bones are pretty good lessons already, and I don't quite see what the broken bones add there.

As someone who broke a wrist by rear-ending a car on my 100cc scooter I must respectfully disagree. A broken bone is way superior learning experience compared to some bruises.

As in: you painfully ran into other things on your 100cc scooter before, but only when you actually broke a bone, did you actually stop driving dangerously on it?

Re: How Complex Systems Fail (1998)

#90

Post by khuston »

tptacek wrote: post #16

I'm a broken record on how important I think this document is, and that it's hard to appreciate it until you've had extended experience with complex systems actually failing. The most commonly cited subtext or thrust of it is that "root cause analysis", at least on complex systems, is a fools errand. Something goes wrong, say, in a distributed lock system, and your whole deployment system enters a metastable failure…

“Root cause analysis”, like “single point of failure”, is often misunderstood. A root cause analysis often finds multiple root causes. And a system can have multiple single points of failure.
Post reply on HN