71–80 of 90 posts
Whenever I see this [excellent] paper, I am always struck by the first sentence, in the first section: > All of the interesting systems (e.g. transportation, healthcare, power generation) are inherently and unavoidably hazardous by THE own nature. (Emphasis mine) I am not sure if that's a typo, or some writing convention that my uneducated mind can't grok.
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…
>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…
- by a plain reading it's clearly singular; seeing beyond that requires at least some effort (e.g. curiosity, education... but also authority, responsibility, time)
- there are lots of people dealing with complex system failures that haven't been exposed to any of the relevant theory... tech folk, but also mgmt, comms (which can be more problematic)
- concluding with a single cause is frequently less work
- concluding with a single cause is frequently convenient (e.g. pinning the blame on a single vendor, component, person)
That's why it's helpful to introduce terminology that points everyone's brains in the right direction from the very start, e.g. contributing factors.
(also common sense isn't real)
Earlier quoted context omitted.
I am also a broken record about Grug-brainedness, but I don't need to be so repetitive about it because so many other people are too.
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…
Earlier quoted context omitted.
> "root cause analysis", at least on complex systems, is a fools errand. Not when properly understood--which, to be fair, it often isn't. The proper purpose of root cause analysis is to answer the question: does this failure mean I need to change something about this system? If the answer turns out to be yes, the thing that you need to change gets called the "root cause" of the failure. Of course that's a misnomer, s…
I don’t blame people for being confused about the term in software — it’s a bit more straightforward in manufacturing, for example. That said, if you look at a system that failed and determine a root cause analysis is pointless, you may have just stumbled upon your root cause.
Earlier quoted context omitted.
> One of the big issues schools and pedagogy in general struggle with is that our environment is far too safe in too many ways. For kids there is too few ways to learn from failures. Its cause we already learned from our failures and make the world a safer place. In my youth we climbed on trees, one of my friend fall down broke his arm, the doctor couldn't fix it and he can not move the hand for the rest of his live.…
No. I'm making a claim that the world is too safe from a perspective of my students. I see it very clearly that a lot of anxiety actually originates from fear. They are afraid to explore environment because they are not allowed to do it. They are afraid of conflicts because they are not allowed to learn to resolve these themselves. They are afraid of resolve any of their problems themselves because they are not allow…
I think about the things I use daily from my math-focused high school and college career… it’s the social skills I learned in team competitions.
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…
It's not just a matter of people taking the phrase literally: - by a plain reading it's clearly singular ; seeing beyond that requires at least some effort (e.g. curiosity, education... but also authority, responsibility, time) - there are lots of people dealing with complex system failures that haven't been exposed to any of the relevant theory... tech folk, but also mgmt, comms (which can be more problematic) - con…
> (also common sense isn't real)
I prefer Murphy's styled variant:
- common sense isn't
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…
All things equal you're always better off ruthlessly killing complexity. Cook (I know you're not rebutting him) is focused on the problem of unavoidably complex systems. A big server running a single instance of Postgres is great, and you should absolutely use that architecture if you can. But real-world constraints can break the architecture: need it running in multiple locations, with a single global view, with str…
The 80:20 rule still lives.