Proximate vs. Root Causes: Why You Should Keep Digging to Find the Answer (2017) | Hacker News Reader

Proximate vs. Root Causes: Why You Should Keep Digging to Find the Answer (2017)

fs.blog

66 pointsingve17 comments

Post-accident attribution to a 'root cause' is fundamentally wrong. - Richard I. Cook, MD. 'How Complex Systems Fail'.

In the complex world, the notion of 'cause' itself is suspect; it is either nearly impossible to detect or not really defined - another reason to ignore newspapers, with their constant supply of causes for things. - Nassim Taleb

... via https://github.com/globalcitizen/taoup

I think the correct way to view this is to try to find the points of maximum leverage. The root cause is always the Big Bang. We already know that, so it's kind of pointless to look for it. What you're interested in is what can be changed.

These will be different depending on your perspective/level of power. For a SWE, it will be something like, "If we had monitoring of this variable, we would have gotten notified faster." Or, "If we had this type of testing, we'd prevent this class of errors." For a VP, it will look more like, "If our incentive structure were changed this way, or if our dev infra team built this kind of tooling, my SWEs would be better enabled to prevent this outage." Often there will be more than one point of leverage, but you only have so much time in your life, so the question is which one is most important or likely to be effective.

Examples of points of non-leverage are, "Joe submitted this busted CL." That is in the past and is not changeable. If Joe is in a habit of submitting busted CLs, he might need counseling, a PIP, or failing all else, to be fired. However, typically the submission of broken CLs is a systemic problem, not a case of a single sub-par engineer. You have to find the leverage that will allow you to change the system.

Agreed, after identifying contributing factors or manageable interfaces process-oriented fixes are most powerful. That's why CI/CD is so awesome, RCS/VCS pre-commit and post-commit hooks allow you to automate the checklists you need to solve entire categories of issues.

It should be called casualty chain analysis. Even though newspapers are awful, and proper RCAs are hard, Taleb likes to diss on anything and everything not invented by himself, without offering much.

It's true that in a complex world, there isn't going to be a single cause for anything significant; there will be multiple causes and there can be complex relationships between them. The article recognizes that very point:

"The issue with root cause analysis is that it can lead to oversimplification and it is rare for there to be one single root cause."

But that is not at all the same as the notion of cause itself being suspect. Taleb on that point is simply wrong.

>> "The issue with root cause analysis is that it can lead to oversimplification and it is rare for there to be one single root cause."

Root cause analysis is a complex and varied topic, discounting it so easily is an oversimplification.

This misattribution is something America loves to fall for. And we react in _gigantic_ ways against the wrong thing. Communism, Unions, Vietnam, Saudi Arabia, Iran, Central America, Iraq, the environment. We are great at solving the last big problem in the most headon disastrous way. We only react, never predict.

We treated Mexico like sht, if we helped build her up, we both would be a solid position right now. Our war on drugs directly fueled a bloody civil war that has and is displacing millions. The war on drugs was the problem, it raised the price of drugs that made something both attractive and illegal, perfect combo. It is like a cryptocurrency called DistableCoin, where you can mine for more by attacking the state.

The root cause is a direct physical cause, but the problem space is the problem. We need to go up-dimension, to project the problem into lots of different lower dimensions. Lots of cut off roasts in the world. The next level of meta is to ask why people cook their own food. Then one asks why the have to eat at all? Why are they biological? Why are they physical?

I tend to prefer to frame it slightly differently as "given this same situation again in the future, how do i ensure that the outcome ends up favorably for me instead?" or "how do i enure that i don't encounter such situations in the future?"

The root cause to me is only useful in that it might provide insight in how to improve my life going forward.

I think included in that framework is also, "thing over which I have the most control or could be controlled".

We don't say the root cause is that time flows forward. Or that gravity can't be stopped or shielded. Or that I can't directly copy my ideas into your head w/o playing out a story. Direct teleportation of knowledge, feelings, thoughts, arguments and truths. Root causes are like the free variables. The universe is the fixed.

Is it just me, or does this look more like a propaganda piece to confuse and guilt trip employees into learning in their free time than an attempt to explain anything? Seriously, who comes up with these examples?

Every action has consequences (also commonly called karma) and every effect has its causes. And that's about it. Picking an arbitrary cause and insisting it's special doesn't look very constructive from here.

> guilt trip employees into learning in their free time

If you went to university, not only did you learn in your free time but you _paid_ to learn in your free time.

Why should the calculus suddenly flip when you get a job and all of a sudden you should only have to learn when someone is paying for you to do it?

I often read the comments section before reading the article because it gives me an indication if I want to read the article. In this case, your comment made me very curious. Keep in mind that my point of view is coloured by the fact that I was looking for something out of the ordinary.

I found the examples fairly innocuous. It makes me wonder if you have been recently getting criticism that you consider unfair. It's easy to have your mind latch on to that kind of thing. I think it is especially easy if you consider the advice given to be unsound.

In this case the situation is that the person is laid off from their job and they are considering the causes. It is interesting that all of the causes listed are their own fault. While it is not discussed in any detail in the article, I think this is actually a big part of doing root causes analysis. It is not useful to spend a lot of time doing analysis on things that you can do nothing about. I think this is why the author is focusing on "what could I do differently".

I found your comment of "propaganda piece to confuse and guild trip employees into learning in their free time" to be interesting. Now, again, keep in mind that I'm an older guy who is much nearer retirement than starting out and that my biggest fault at work is that I work too hard (especially these days because my body can't handle it and I end up less productive than I could be). However, I have found that the sentiment you seem to endorse is often quite counter productive for software developers. If you are not a software developer, then maybe this won't apply, but it might be interesting anyway.

I don't know if you are young or old, experienced or relatively new at this stuff. However, if I could only give young developers a single piece of advice it's that you can't stop learning and that your boss probably won't pay for all the learning you need to do. I'm still able to code professionally, despite my white hair, because I spend an inordinate amount of time learning both on and off the job. I can do remote development from rural Japan because I can pick up new fashion and become proficient with it as fast as my employer needs me to be.

When I first started, the good jobs I had available to me required me to know JCL, APL, COBOL and DB2. And while you can probably make a decent wage doing this kind of work now, you aren't going to have any choices about where you live (or probably even what colour of tie to wear...).

It sucks in many ways. I wish any of my previous employers had decided that they wanted to allow me to spend a big chunk of my work day using technology and techniques that they didn't need yet. But... There are like 10x more programmers now than there were when I first started. It's much easier to simply lay off the previous ones and bring on the new ones. First, they'll be trained on the new technology. Second, they'll be eager to use it. Third, they'll be half the price.

Just going to say it again to let it sink in. I compete against people who already know the new technology, have more energy than me and who cost half my salary. Saying, "But I'm old", just doesn't cut it for keeping your job ;-)

It's not that I don't understand what you are saying, but I think your conclusions are in many ways dangerously naive. If it's the case that you've got 30-40 years of experience and it's all worked out for you with that kind of attitude, then I will rush to your side to learn your secret. If not, I hope you will consider a more pragmatic view of navigating through your career.

And, yes, I think the kind of thinking promoted by this article can be helpful.

Not much, no.

I can think of several causes that are more likely in the described scenarios. The fact that younger employees often are easier and cheaper to exploit is fairly well known, as is the fact that plenty of employers don't mind playing that game in the name of awesome profits. The total disregard for experience goes a long way to explaining why nothing works very well these days.

To me it sounds more like you have a horse in this race yourself, like you wouldn't mind guilt tripping employees in the name of profit.

If profit was a motive for me, then I would not keep doing this job for so long ;-) Good luck, anyway. I occasionally try to reach out if I think it might be useful to the person writing. It seems like I wasn't successful this time.

Reply on news.ycombinator.com