Comment by pdonis
5 hours ago
> "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, strictly speaking, but that doesn't mean you answered the actual question wrong.
Cook doesn't object to postmortems and to using hard failures as opportunities to spot interventions (though, remember, all practitioner actions are gambles). The issue is in attempting to identify a single privileged root cause.
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.
> 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?
does this failure mean I need to change something about this system?
It's safer to say 'does this failure mean I need to change the system?'. Otherwise you're still facing the single cause trap.
> Otherwise you're still facing the single cause trap.
"Something" does not have to mean "one single thing". But I would be fine with your phraseology if it ended up making it clearer to whoever was doing the analysis.