

Root cause analysis by asking "Why" 5 times. - nate
http://blog.inklingmarkets.com/2009/11/5-whys.html

======
adriand
My two-year-old son is adept at this technique. Unfortunately I am not sure he
always listens to my responses. An example copied from one of my recent blog
posts:

We have interesting conversations in the front hallway on weekday mornings
when he tries to prevent me from going to work.

“No Daddy go!”

“Daddy has to go to work.”

“Why Daddy work?”

“Daddy has to work so that he can make money.”

“Why money?”

“Because we need money so that we can buy food.”

“Why?”

“Because we need to eat.”

“Why?”

Why indeed? I used to believe that when I had a child, I would always try to
explain things to that child and never resort to the pat answers I’d hear from
other parents (”just because”). My child is only two and he is already
defeating this goal. Why DO we need to eat?

You can answer that question, sure, but ask enough “whys”, and you’ll find
yourself trying to explain the nature and reasons for existence of the
universe – to a two-year-old.

~~~
makmanalp
Sometimes there's nothing wrong with "I don't know".

~~~
abstractbill
_Why_ don't you know? ;-)

------
dschobel
Also a great way to distinguish good programmers from bad.

If they can't explain a phenomenon beyond "when I do <x> it
works/breaks/quacks like a duck" and are satisfied with that level of
understanding, that's a massive red-flag.

This is a very efficient way of picking out even the young guys & gals who
will end up being good engineers.

------
RevRal
More specifically, turning this into a habit will bring out the cached
ideas/thoughts that you use.

Cached ideas/thoughts are conclusions that you or someone else has made, that
you accept as a useful variable that you can plug into situations when
necessary. Problem is, these conclusions are sometimes wrong. So, after you
make a habit of "asking why" until you are satisfied, you'll find yourself
catching these cached thoughts even in every day speech.

But, there are some things that are best to just accept. Like, some uses of
CSS. I am fully comfortable using other people's fixes without completely
understanding how it works.

There is a balance that needs to be found. It's like memorizing things by rote
vs. knowing why said things work. It is as much a mistake getting caught up
figuring out why everything works as learning everything at surface level.
But, the latter is far more frequent.

------
yagibear
A better principle is ABQ, since few things have a neat single root cause that
some magic number of questions converges on:

"5. Why? - I have not been maintaining my car according to the recommended
service schedule. (fifth why, a root cause)"

6\. Why? - Because I didn't think it a high priority relative to my other
activities

7\. Why? - Because ...

------
theprodigy
All entrepreneurs need to put their ideas through the "why" test at least 5
times. If you have concrete reasons and answers, then your ideas are good and
well thoughtout.

Candidates that can't answer the why test all 5 times needs to think things
through a little more.

------
udfalkso
This first scene from HBO's Lucky Louie is the best example of this:
<http://www.videosurf.com/video/lucky-louie-101-58075787>

~~~
knotty66
Never seen Lucky Louie but the similar scene from Louis C.K. standup is
fantastic.

<http://www.youtube.com/watch?v=4u2ZsoYWwJA#t=7m00s>

------
btilly
I found <http://www.startuplessonslearned.com/2008/11/five-whys.html> to be a
better explanation of this phenomena.

------
pobrien
As other people have pointed out, this doesn't exactly arrive at a "root"
cause, just a convenient one for the asker. You can keep asking "why?" until
the problem is no longer your fault.

------
ero5004
Interesting but does 5 times work for everything or just some specific
problems? I would agree that constantly asking why is a good thing but I'm
just not sure about this 5 thing

~~~
nkohari
It's just a rule of thumb, like the "rule of 7" when it comes to cognitive
load. The point is to continue past the surface issue until you find the real
problem. Fixing a lower-level problem (like not having automated testing) has
much more value than fixing a higher-level problem (like fixing regressions
when they occur in your software).

