4 ms·
There's some good stuff here, but it also feels like it's a deep analysis of a straw man rather than of real industry practice. > At its core, RCA posits that
by mjb 5y ago
There's some good stuff here, but it also feels like it's a deep analysis of a straw man rather than of real industry practice.
> At its core, RCA posits that an incident has a single, specific cause or trigger, without which the incident wouldn’t have happened
Does it?
None of the teams I've worked with that practice root-cause analysis, or use the term 'root cause' assume that incidents have a single specific cause or trigger. In fact, most teams seem very comfortable exploring complex trees of causality, no matter what they call their post-mortem process.
> None of these alternatives are fixed as easily as reverting the one line. None of them suggest that they stem from the same ‘root.’ And yet, all of these alternatives are more fundamental to resilience than the one line of a configuration file.”
“In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.” (Douglas Adams)
There has to be a logical stopping point to investigations, because at some point they just become metaphysics. Even getting to the point of "we don't make enough revenue to fix this" isn't really helpful, because everybody knows that already. Instead, and somewhat crucially, choosing which actions to take after an event needs to be done in context of the constraints on the business. Sometimes those constraints are a problem, but it may be possible to improve the situation even within those constraints. Throwing our hands up and saying that we can't make improvements because of the constraints isn't really that helpful.
Dekker is spot-on that it's a construction, but that's the point, not the problem.
> Our focus on language in reports is informed by research into the relationship between language and how people perceive and/or assign blame.
I just don't believe this. Bad organizations are going to assign blame no matter what language they use, better organizations won't. The problem is the culture, not the language, and it really doesn't seem to me that changing the language will change the culture. Instead, it'll just lead to double-speak.
They even say this:
> RCA is often a path that ends squarely at a person’s feet. “Human error” is a quick and easy scapegoat for all kinds of incidents and accidents, and it’s deceptive simplicity as a root cause is an inherent part of its larger-scale harmful effects. It’s comforting to frame an incident as someone straying from well-established rules, policies, or guidelines; simply provide more training, and more guardrails and checklists in the future!
then this:
> we can say now that there’s only a small amount of incidents (less than a percent) that directly call out human or operator error as a “root cause.”
Which just don't seem consistent.
- mytailorisrich 5y ago> Does it? It does not, indeed. There may be multiple and complex root causes. The point is to analyse a problem beyond its immediate symptoms in order to get to the 'root' cause(s) and improve quality in depth. It's not an 'artificial stopping point', either, as the article also claim.
- alexvoda 5y agoMaybe just like the title, the distinction is whether you interpret root as in the plant part or as in the data structure. In a plant, starting from the trunk, and going towards the source, a root branches into smaller and smaller bits. On topic, the root cause would be a combination of multiple contributing factors all coming together. In a tree data structure, the root is a singular node. On topic, the root cause would be a singular reason. I never understood why in computer science, the root if a tree data structure is called the root and not the trunk.
- alexvoda 5y agoAdditionally, version control looks nothing like a tree, but oftentimes we have a trunk. Computer scientists are bad botany.
- mytailorisrich 5y agoRoot cause analysis has nothing to do with data structures. Obviously it's an idiom ("the root of the problem") based on the plant part (like 'tree' data structures). In any case there is not point arguing on such semantics, especially if it's to argue on overly narrow definitions. The "root cause" of an issue is very often not singular and therefore "root cause analysis" is not an attempt to find a singular cause.
- deleted 5y ago[deleted]
- wahern 5y ago> There has to be a logical stopping point to investigations, because at some point they just become metaphysics. The law understands this point very well, which is why it has developed concepts like Proximate cause: https://en.wikipedia.org/wiki/Proximate_cause https://en.wikipedia.org/wiki/Proximate_cause Rules of evidence also arose to prevent investigations and analyses from getting lost in the weeds. See https://en.wikipedia.org/wiki/Evidence_(law) https://en.wikipedia.org/wiki/Evidence_(law) Though they're highly tuned to witness testimony and similar mushy issues--intent, etc--so don't translate well. But whenever you hear about a court tossing out evidence, or doing something seemingly inane like (in a recent high-profile case) preventing a juror from using a smartphone to "zoom in" to a piece of evidence, it's precisely this role that is being (or attempted to be) primarily served--preventing scope creep and the endless bickering that will inevitably result. The rabbit hole is bottomless, and whatever stopping points you choose are often arbitrary--they especially seem so to outsiders.