upvote
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.

reply
> 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.

reply
> 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?

reply
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.
reply
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.

reply
> 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.

reply