I don't force it 5x but asking why was the best lesson I learnt working with users/clients as people tend to talk about solutions and not the problems. That's also where my nickname comes from.
Feature requests are really prone to this. Customers will only ask for features they can imagine, not the ones that really solve their problem. A significant chunk of the time the customer is better served by a different feature that takes less work.
This is why i don't like tender-based software projects. The tender already describes the features needed, and they must be built even if they are suboptimal for the problem domain.
I usually ask, "What problem are you trying to solve?", to anyone who brings me a solution instead of a problem, but it comes down to the same thing. I guess I don't even really know which question would be more efficient at getting the real answer.
A blind drunk man was jaywalking and was hit by a distracted and inexperienced driver and died. Why did he die? There likely isn't a singular root cause. There are 5 potential singular root causes, but they are a subset of the 5-factorial potential combinatorial root causes.
I agree that solutions before problems is bad, but the five whys is problematic simply because it promotes the idea of singular root cause which is almost inevitably a fallacy when analyzing complex systems. There are often conceivably millions of overlapping and/or interacting causes to an observable problem. Sometimes, trying to boil causality down to a single item is merely missing the point, but very often it is much more problematic. Unintended consequences from solutions derived from improperly attributed singular root causes can be terrifying.
I've tried forcing it 5x and found that the fifth Why is exactly the point where they get annoyed and stop talking to you. So there may be a magic insight at the fifth Why but you'll never hear it :)
> people tend to talk about solutions and not the problems
Hard to make this any clearer. To expand a bit on this, most of the times the solutions they talk about are of course expressed in terms of what they already know, which makes communication that much harder. It's a key aspect to keep in mind, and one that ideally both parties, but at least the one that's taking the job, needs to be aware of.
Otherwise it's like visiting a physician and telling them the diagnosis instead of the symptoms.
As someone who likes to fundamentally understand processes and underlying reasons. It does take some practise though to get at the heart of the matter and propose alternative solutions that work without being abrupt or like "c'mon, etc?". People higher up tend to be rather attached to their solutions even though after chatting for a bit it becomes increasingly obvious a different approach would get them what they want and often reduce human error factors and/or make effeicent :)
I'm figuring this out slowly, getting "it" though.
Why is there no filter on the intake? It was proposed, but declined by management as "too costly".
Why is it too costly? Because cutting visible costs is perceived as saving money and therefore Good, whereas prevention and maintenance are perceived as unnecessary, because Bad Stuff Just Happens Regardless.
Why? Because people suck at statistics ("if we can't eliminate a risk altogether, there's no point in trying, let's just forever keep fixing the fallout") and because Fixing Broken Stuff Is Someone Else's Budget, Let's Pass The Buck.
(Or at least, that's the way things tend to turn out when you decide to go beyond the immediate cause-and-effect)
Just as "Five" is really just a rule of thumb as pointed out by other people, "Why" is really just a rule of thumb too. "What can we do to prevent the underlying problem?" just isn't as catchy, but it's closer to what you should be really asking.
"People suck at statistics" is not an answer to that question. "Train people" is an answer, but only an answer. You've also got "something to make us more robust to bad statistics" and, no sarcasm, "trust the statistics less in the future", and several other such things. Another one I'd consider, for instance, is that if some set of statistics is truly bringing negative value to the process, stop collecting them.
Also, "we've got fundamental management issues" can be a valid answer. If you're in an engineering environment but your management isn't able to work that way, try to do something about it. In the end, it is not out of the question for the process to produce "I need a different job", though I think one has a professional obligation to at least try to fix the underlying problems first.
This is a process in which neither blind idealism nor blind cynicism is the road to success. If you're just getting cynical answers, that's not a reflection of the process, that's a reflection of your cynicism being too strong. Tone it down. Don't get rid of it. I would never suggest getting rid of it. But tone it down. And get more specific than "people generally suck" or anything that is simply a variant on that.
I was also disappointed that the example list didn't get into people issues.
But it is not as simple as prevention vs. cost-cutting. In any place, there are thousands of things that might prevent a problem, but which of them are worth doing? One of many strategies for selecting the right precautions is an evolutionary one: fix the ones that caused problems in the past.
There seems to be some confusion/mis-interpretation about the 5 part.
This is called 五回のなぜ in Japanese ("Go-kai no naze," or Why Five Times) and refers to root cause analysis. Of course the number of times the process need be repeated until the root cause is identified is variable. Five in this case is merely a jingly mnemonic, as Japanese people are so fond of.
Exactly. This is all about getting to root causes.
I learned this working in a manufacturing environment for several years the was implementing the Toyota Production System and all the things that are a part of it like Kaizen, Kanban, etc.
After I left I thought it was too bad that all that good process was locked into the manufacturing world. I've seen it creep in more and more, often under the classification of UX with understanding user flows and actual problems of usability on a site (another area where asking why 5 times is very helpful to get to the root of a user's feedback).
I've also seen what I call "kanban flavored agile" be one of the most effective engineering processes for environments with ever changing requirements who don't need the rigid deadlines of sprint-based planning. When I saw it in manufacturing it was all about "just in time delivery" meaning a factory could easily switch production lines when suppliers missed deliveries (or delivered defective goods) or a machine broke down, etc. Which when you compare to the sorts of things that happen most every day in a typical software organization doesn't sound all that different.
I've always thought the idea behind "5" was to encourage you to ask more than once or twice. I think it's natural to stop after once or twice but you usually get the good stuff further along. Why is the sky blue? The atmosphere. Oh, ok -- I got it. There's a lot more to the story.
I know a certain 3 year-old who uses a similar trick to collect knowledge about the world. Not being sarcastic here; orgs can learn a lot from young children about how to acquire new skills and make decisions in the face of uncertainty.
Before they can even walk infants learn to judge whether they're about to crawl off a cliff -- a skill the yahoo board (for example) could have really used.
It's an excellent technique for learning unfamiliar domains (which is almost everything, for a 3 year old). If you don't have a strong framework to fit new data into, ask "why?" a bunch of times and people will hand you relevant pieces of that framework.
Babies learn to crawl, then learn to not crawl off cliffs. Then they learn to walk, then they learn to not walk of cliffs. So there is a point after they won't crawl off a high drop, that they will just walk off it.
I survived several years in a Six Sigma organization. The Five Whys was one of my favorite 'tools' despite the 'Black Belts' dragging the process out much longer than required.
I've never seen a methodology burn through more easel pads.
I preach this whenever i can in regards to social issues. Whenever one of your friends, or any person, acts in a way that you don't agree with (being rude, sleeping around etc), be patient and try to think about possible underlying causes; it's much more fruitful to engage the underlying unhappiness (carefully) than to react hastily to the immediate situation.
I love Feynman. He was an incredible teacher but this video has always annoyed me a little. The interviewer asked a pretty clear question (explain why magnets repel or attract depending on how you align them) but Feynman goes on a bit of a rant about how the guy won't understand if he explains things as he (Feynman) understands it and that he (Feynman) doesn't know how to explain it to him (interview) in ways he would understand.
For someone as excellent at sharing knowledge it seems like Feynman just didn't want to do the interview any longer. He sounds and acts a little pissed off with the question.
Sometimes I have multiple solutions to a problem in mind and want to throughly investigate them, but run into a minor road block when investigating one of them.
In forums, some of the most annoying threads are people that are trying to help you "solve your real problem" instead of helping with the specific question at hand.
What usually happens as one of the 'solve your real problem' people is context. You searched for a path and ended up with a path of A->B->C->D->#block->F but you only tell the group about D->#block and all the readers are guessing how you constructed a path to get to D. The destination of F is often also not clear and missing from the problem description. Even if the reader can approximate a route from A->...->D->#block->F they have a chance of applying their own experience, because often D->#block is a true dead end of the hopeful path of A->F.
Too many systems have contextual inputs that only make the solution apparent with adequate context, so really we are hoping for A and F.
You know what's even more annoying? People who ask very misguided questions, because they're obviously trying to solve a wrong problem, and yet insist on doing things their own way even though it will lead them nowhere. They're much more common than people who know what they're talking about, and it's usually easy to tell them apart based on the communication style.
This might be the deepest issue with Stack Overflow.
People post some bizarre objective/problem (because the bizarre stuff is what you need to ask about), and half the comments are people asserting that their goal is wrong.
There's no clear solution, though, because half the time the goal really is misguided, and the other half the "right" way is for some reason unavailable. The best answer I've seen is for commenters to offer "you really shouldn't do that normally, but you could try this to make it happen".
One thing that stuck out to me was how long everything took to figure out on the Toyota Production System. Ohno spent decades streamlining processes. The timeline is in the inside cover of my copy of the book.
Fascinating read, and easier to read than some other "Toyota Production" books written by academics. Recommend.
Keep pressing next on that page to see a few more bite size pieces of Toyota wisdom. They won't change your life, but for 30 seconds or so you'll associate Toyota with intelligence and innovation.
The first time I heard about this was from Joel Spolsky of Fogcreek/Stackoverflow. It really changed how I've approached postmortems and encouraging those to really drive deeper into problem solving. http://www.joelonsoftware.com/items/2008/01/22.html
Ask why more than twice at my job and you'll get in trouble. Sometimes the boss, and the customer, doesn't want to be asked. I think this idea is too aggressive and indicative of high pressure sales tactics.
You can often avoid asking the "why" question explicitly. If you instead ask about the unintended consequences of the current policy, people will elaborate on the reasons why the situation is undesired, without you asking for it.
For example, in the third question of the article you could ask "Is this the usual level of lubrication?" and you will reach the same conclusion of "No, the oil pump on the robot is circulating less oil than normal."
"Why?" is a fine response to a statement of intent; but "How do you know that?" as a response to a declarative statement used for motivation can often be more enlightening.
(This kind of epistemological work-out is handy in lots of other situations. When the JWs or Mormons show up at your door, asking "How do you know that?" repeatedly is often all that you need to do until they give up and go away.)
[+] [-] iaskwhy|10 years ago|reply
[+] [-] Joeri|10 years ago|reply
This is why i don't like tender-based software projects. The tender already describes the features needed, and they must be built even if they are suboptimal for the problem domain.
[+] [-] wccrawford|10 years ago|reply
[+] [-] saosebastiao|10 years ago|reply
I agree that solutions before problems is bad, but the five whys is problematic simply because it promotes the idea of singular root cause which is almost inevitably a fallacy when analyzing complex systems. There are often conceivably millions of overlapping and/or interacting causes to an observable problem. Sometimes, trying to boil causality down to a single item is merely missing the point, but very often it is much more problematic. Unintended consequences from solutions derived from improperly attributed singular root causes can be terrifying.
[+] [-] hammock|10 years ago|reply
[+] [-] kidmenot|10 years ago|reply
Hard to make this any clearer. To expand a bit on this, most of the times the solutions they talk about are of course expressed in terms of what they already know, which makes communication that much harder. It's a key aspect to keep in mind, and one that ideally both parties, but at least the one that's taking the job, needs to be aware of.
Otherwise it's like visiting a physician and telling them the diagnosis instead of the symptoms.
[+] [-] SoreGums|10 years ago|reply
As someone who likes to fundamentally understand processes and underlying reasons. It does take some practise though to get at the heart of the matter and propose alternative solutions that work without being abrupt or like "c'mon, etc?". People higher up tend to be rather attached to their solutions even though after chatting for a bit it becomes increasingly obvious a different approach would get them what they want and often reduce human error factors and/or make effeicent :)
I'm figuring this out slowly, getting "it" though.
[+] [-] tedmiston|10 years ago|reply
No, no, no!
[+] [-] erac1e|10 years ago|reply
[+] [-] Piskvorrr|10 years ago|reply
Why is it too costly? Because cutting visible costs is perceived as saving money and therefore Good, whereas prevention and maintenance are perceived as unnecessary, because Bad Stuff Just Happens Regardless.
Why? Because people suck at statistics ("if we can't eliminate a risk altogether, there's no point in trying, let's just forever keep fixing the fallout") and because Fixing Broken Stuff Is Someone Else's Budget, Let's Pass The Buck.
(Or at least, that's the way things tend to turn out when you decide to go beyond the immediate cause-and-effect)
[+] [-] jerf|10 years ago|reply
"People suck at statistics" is not an answer to that question. "Train people" is an answer, but only an answer. You've also got "something to make us more robust to bad statistics" and, no sarcasm, "trust the statistics less in the future", and several other such things. Another one I'd consider, for instance, is that if some set of statistics is truly bringing negative value to the process, stop collecting them.
Also, "we've got fundamental management issues" can be a valid answer. If you're in an engineering environment but your management isn't able to work that way, try to do something about it. In the end, it is not out of the question for the process to produce "I need a different job", though I think one has a professional obligation to at least try to fix the underlying problems first.
This is a process in which neither blind idealism nor blind cynicism is the road to success. If you're just getting cynical answers, that's not a reflection of the process, that's a reflection of your cynicism being too strong. Tone it down. Don't get rid of it. I would never suggest getting rid of it. But tone it down. And get more specific than "people generally suck" or anything that is simply a variant on that.
[+] [-] adrianratnapala|10 years ago|reply
But it is not as simple as prevention vs. cost-cutting. In any place, there are thousands of things that might prevent a problem, but which of them are worth doing? One of many strategies for selecting the right precautions is an evolutionary one: fix the ones that caused problems in the past.
[+] [-] waxenfigurine|10 years ago|reply
This is called 五回のなぜ in Japanese ("Go-kai no naze," or Why Five Times) and refers to root cause analysis. Of course the number of times the process need be repeated until the root cause is identified is variable. Five in this case is merely a jingly mnemonic, as Japanese people are so fond of.
[+] [-] thisjustinm|10 years ago|reply
I learned this working in a manufacturing environment for several years the was implementing the Toyota Production System and all the things that are a part of it like Kaizen, Kanban, etc.
After I left I thought it was too bad that all that good process was locked into the manufacturing world. I've seen it creep in more and more, often under the classification of UX with understanding user flows and actual problems of usability on a site (another area where asking why 5 times is very helpful to get to the root of a user's feedback).
I've also seen what I call "kanban flavored agile" be one of the most effective engineering processes for environments with ever changing requirements who don't need the rigid deadlines of sprint-based planning. When I saw it in manufacturing it was all about "just in time delivery" meaning a factory could easily switch production lines when suppliers missed deliveries (or delivered defective goods) or a machine broke down, etc. Which when you compare to the sorts of things that happen most every day in a typical software organization doesn't sound all that different.
[+] [-] methehack|10 years ago|reply
I've always thought the idea behind "5" was to encourage you to ask more than once or twice. I think it's natural to stop after once or twice but you usually get the good stuff further along. Why is the sky blue? The atmosphere. Oh, ok -- I got it. There's a lot more to the story.
[+] [-] mongeone|10 years ago|reply
[1]http://eow.alc.co.jp/search?q=%E8%AA%A4%E8%A7%A3&ref=sa
[+] [-] icebraining|10 years ago|reply
[+] [-] awinter-py|10 years ago|reply
Before they can even walk infants learn to judge whether they're about to crawl off a cliff -- a skill the yahoo board (for example) could have really used.
[+] [-] Bartweiss|10 years ago|reply
[+] [-] ZeroGravitas|10 years ago|reply
Babies learn to crawl, then learn to not crawl off cliffs. Then they learn to walk, then they learn to not walk of cliffs. So there is a point after they won't crawl off a high drop, that they will just walk off it.
https://www.youtube.com/watch?v=WanGt1G6ScA
[+] [-] stevewillows|10 years ago|reply
I've never seen a methodology burn through more easel pads.
[+] [-] erac1e|10 years ago|reply
[+] [-] hoodoof|10 years ago|reply
"Why do vehicle manufacturers lie about emissions?"
"Why do vehicle manufacturers lie about emissions?"
"Why do vehicle manufacturers lie about emissions?"
"Why do vehicle manufacturers lie about emissions?"
[+] [-] ajuc|10 years ago|reply
[+] [-] rmc|10 years ago|reply
[+] [-] MrJagil|10 years ago|reply
[+] [-] elthran|10 years ago|reply
Some people enjoy things that other people don't approve of.
[+] [-] KhalilK|10 years ago|reply
0.http://youtu.be/MO0r930Sn_8
[+] [-] satysin|10 years ago|reply
For someone as excellent at sharing knowledge it seems like Feynman just didn't want to do the interview any longer. He sounds and acts a little pissed off with the question.
[+] [-] rileymat2|10 years ago|reply
In forums, some of the most annoying threads are people that are trying to help you "solve your real problem" instead of helping with the specific question at hand.
[+] [-] xemdetia|10 years ago|reply
Too many systems have contextual inputs that only make the solution apparent with adequate context, so really we are hoping for A and F.
[+] [-] xyzzyz|10 years ago|reply
[+] [-] Bartweiss|10 years ago|reply
People post some bizarre objective/problem (because the bizarre stuff is what you need to ask about), and half the comments are people asserting that their goal is wrong.
There's no clear solution, though, because half the time the goal really is misguided, and the other half the "right" way is for some reason unavailable. The best answer I've seen is for commenters to offer "you really shouldn't do that normally, but you could try this to make it happen".
[+] [-] ideaoverload|10 years ago|reply
[+] [-] gregpilling|10 years ago|reply
One thing that stuck out to me was how long everything took to figure out on the Toyota Production System. Ohno spent decades streamlining processes. The timeline is in the inside cover of my copy of the book.
Fascinating read, and easier to read than some other "Toyota Production" books written by academics. Recommend.
[+] [-] exodust|10 years ago|reply
[+] [-] anotheryou|10 years ago|reply
Probably nobody is assigned to the task of installing filters in new machines and the next one will fail again...
[+] [-] ck2|10 years ago|reply
2. Why still? 3. Why still years later? 4. Why a decade later? 5. Why not fix it?
http://www.edn.com/design/automotive/4423428/Toyota-s-killer...
This is why my car is the last model with mechanical accelerator and steering.
[+] [-] jsmeaton|10 years ago|reply
[+] [-] jdking|10 years ago|reply
[+] [-] Overtonwindow|10 years ago|reply
[+] [-] TuringTest|10 years ago|reply
For example, in the third question of the article you could ask "Is this the usual level of lubrication?" and you will reach the same conclusion of "No, the oil pump on the robot is circulating less oil than normal."
[+] [-] Tiquor|10 years ago|reply
[+] [-] dilemma|10 years ago|reply
[+] [-] erac1e|10 years ago|reply
[+] [-] jackgavigan|10 years ago|reply
[+] [-] pklausler|10 years ago|reply
(This kind of epistemological work-out is handy in lots of other situations. When the JWs or Mormons show up at your door, asking "How do you know that?" repeatedly is often all that you need to do until they give up and go away.)
[+] [-] bikamonki|10 years ago|reply