The most important lesson I ever learned in this business…
Be cautious or even suspicious when a specification/question is provided in the form of a request for a specific technical solution.
When someone presents a request in this form, the first thing you should do is obtain an understanding of the problem that the solution is supposed to solve.
Anyone that can ask for a specific technical solution should be able to provide that solution themselves. If they have to ask for help in building the solution, then they are most likely simply not equipped to identify it as the solution in the first place, and so they should be guided back to the problem itself.
[Of course, it may be that even with complete understanding the same technical solution is, after all, arrived at – never rule out blind luck!]
An example might be someone asking for help in building a flotilla of reed boats.
- Option 1: Show them how/Help them to build a boat out of reeds
- Option 2: Ask them why they need such a seemingly odd flotilla of boats …
Take option 2 and imagine you receive the reply:-
Because I need to get a few hundred people across a river, and where we are there are no trees nearby so I have no wood with which to build regular boats. There are plenty of reeds though, and I heard about this guy that built a boat of reeds and so I figured I’d do that but I need someone to tell me how to do it.
Then ask them where this river is and where they are. Then imagine that when you learn that where they are, you know that there is already a foot-bridge across the river, just around a bend that they apparently didn’t know about. TA DA!
They presented a request for a solution to a problem without fully understanding their own problem domain. With a proper understanding of the problem domain, the asked for solution is readily identified as misguided – at best – and a cheaper, faster, more appropriate solution identified.
In my experience, when a request comes in the form of a specific solution, 9 times out of 10 there is a better, more appropriate solution. Indeed, quite often it becomes apparent that the asked for solution would not actually have even been a solution at all.
The species of reed at hand may not be suitable for building boats out of, so your flotilla would simply have sunk and your user still would not have made it across the river.
To add insult to injury, you would most likely have been blamed for not building the boats properly!
Understand the problem – only then can you provide the solution.
I can most definitely second that observation!
Also,when you don’t hear about it as a requirement, it can just as well mean you’ll hear about it later on (when they’ll be taking water in the middle of the river).
http://blogs.msdn.com/b/oldnewthing/archive/2006/03/23/558887.aspx
@Moritz: Yep. It’s not a new or especially insightful… um.. insight. I had forgotten – or missed – that Raymond has posted a similar piece some years ago on The Old New Thing. I was actually formally taught this discipline on an SSADM course waaaay back in 1990. What makes it so incredible to me (and not a little depressing) is that it needs to be repeated and that so many practitioners in this industry don’t understand it’s importance, or if they do, have simply not got into the habit of observing it as a matter of course. For me it’s a given… how can I possibly hope to deliver a solution if I (and indeed the user) do not fully understand the problem in the first place?!
I second that emotion, but have run into situations where the client really really wanted that solution and didn’t want to hear about other solutions or to go through a real problem solving session. Sigh.
When it was my own consultancy, I thanked them for their time and left. Once I sold my consultancy and went to work for the person who bought me, I suggested that they might be happier with another one of our staff. One client very happily paid for our guy to do useless stuff for a long time, under the client’s direction. I wouldn’t have been able to stomach it, but some people have more money than good sense.
While I agree with your argument, you have to be careful with issuing this sort of advice. It’s quite aggressive to answer a question with questions of your own.
In person it’s usually not so bad and you can explore options quickly and politely with the person. Online forums though, mainly due to the characteristics of the medium, are full of well meaning but quite condescending examples of experts applying this technique.
In the online world my attitude is unless I have a direct interest in leading the questioner to the “correct” answer my preference is either to decline to answer or to say nothing more than “I don’t know sorry, but happy to help if you need to find an alternative.”
If nobody else gives them a good way to build their reed boats, they then might ask me for assistance. If they give it a go themselves and their boat sinks sure they’ll get wet but that’s a learning experience too.
“What makes it so incredible to me (and not a little depressing) is that it needs to be repeated and that so many practitioners in this industry don’t understand it’s importance”
Indeed. It reminds me of “why is it called common sense when it is so rare”.
(oh btw: your server hates quoting stuff in double angle brackets)
–jeroen
Lachlan said “In the online world my attitude is unless I have a direct interest in leading the questioner to the “correct” answer my preference is either to decline to answer or to say nothing more than “I don’t know sorry, but happy to help if you need to find an alternative.””
Great advice Lachlan, and something that would have been more productive if followed in the NZ Delphi User Group online discussion that led to this post 🙂
@David and Lachlan: Sadly I think some people just don’t appreciate assistance if that assistance means challenging their own thought processes – they just get defensive and “shoot the messenger”. Online or not, some people just can’t be helped. Unfortunately (again online or not) the only way to identify such people is to initially try to help them, then leave them to it when you recognise that they can’t be helped. I’ve actually had it said to me that the notion that sometimes people ask for the wrong thing is a) wrong in the first place, and b) even when/if true that you should just answer the question that is asked and not be concerned with whether it is the right question to answer!! It is at least forgivable to not know any better, but it beggars belief that there are people in this industry that actually think that way as a deliberate and considered approach.
Hang on a sec … let me get this right.
The gist is;
Don’t tell me your solution, tell me the problem – I’ll tell you what the correct solution is. Wow, that’s such an interesting perspective … “Bah, you don’t have a clue what you want, here let me tell you.”
Wouldn’t the person presenting the “problem as a solution” be expert in the problem domain? More so than you, the solution provider. Wouldn’t someone who is not a problem domain expert simply come with the problem and expect you to become expert? Which I think is more likely what has happened in the past [in the solution provider realm] and resulted in the axiom.
The only way you can provide a viable solution – a perfect solution – is to become an expert in the problem domain. Like you did when you used Google Maps to locate the foot-bridge across the river above.
“Anyone that can ask for a specific technical solution should be able to provide that solution themselves.” Not necessarily true.
Finally, why do you care what the problem is if you’ve been given the solution and direction to build it? If I contract you to install a grand piano in my bathroom isn’t your job to make sure it is there and it’s in tune? Why is the fact that I like to play naked [the problem] and the bathroom is the only room without windows any of your concern?
Interesting read though … thanks.
@Dave: No, the “gist” is that otherwise intelligent people often make dumb choices when they *think* they know everything they need to solve their own problems. Asking “why” someone wants you to do something for them will do one of 2 things: 1) confirm that what they ask for is not only what they want but what they need or 2) reveal that they need something quite different from what they want.
Either way, the result of asking “why” is that they have a far better chance of getting the right solution, not merely the solution they asked for.
NOT asking why, and just giving them what they want is much more likely to result in them eventually realising that what they wanted isn’t what they need, but you will be the one blamed for giving them the “wrong solution”, even tho it is what they asked for. This isn’t hypothetical, theoretical philosophising – it’s what happens in the real world in this industry every frikkin’ day.
A perfect, but trivial example, is this StackOverflow question: http://stackoverflow.com/questions/4696919/delphi-virtualstringtree-check-for-duplicates#4697118
Solution asked for: Detecting and removing duplicates from a treeview
Solution needed: Populate a treeview whilst avoiding adding duplicates
Quite, quite different.
Note that the answers for the stated, required solution are for more complex (and inefficient) than the solution that was actually needed.
There seems to be some idea that asking “why” and ensuring that the solution being provided really is what is needed is somehow patronising, condescending or arrogant. That attitude comes from people that don’t actually want *help* they just want service. And that’s fine, there will be plenty of people willing to take your money and do what you tell them, without question, if that’s what you want.
My advice (or rather the advice I am passing on – it’s not my unique insight, but something I was *taught* and which 20 years of experience after learning that lesson has show to be a useful and valid lesson) is aimed at people who wish to be helpful. You don’t have to take it or apply it yourself.
and then there’s the responses you get [after supplying a solution as a problem] from some that go; “You don’t need to cross the river, you need to build a hut”. I wonder if they wave their arm like a Jedi when they do that. It’s too bad that recommending near impossible physical contortions as a response is frowned upon in most groups – if anyone deserves it.
Yea, OK … I was trying to come up with instances where I’ve run into situations where someone came to me with solution instead of a problem. Once one came to mind, they just started pouring in. In every case we ended up sitting down and the first question was … “OK, what’s the problem you’re trying to solve.” This is in the Marine Industry [ships] … I’m not a programmer – I have spent quite a lot of my time investigating/studding the art though so I do understand the topic from that aspect as well.
Thanks again …
Very true. Another related issue with requirements is that the best solution to a requirement is that you find out that the complete requirement is unnecessary.
Often when you have fixed your thinking into solving a problem, you have omitted the phase where you consider whether the problem could be removed altogether.
An example in GUI design is that people tend to code various error checkings when you press OK, for example. But it’s not very convenient to provide good feedback that the input is not correct when the action is “accept this and go on”. On the other hand, if you keep the OK button disabled until the input is correct, the GUI logic is typically both easier to implement and use.
Also it reminds me of the main target of extreme programming: to create the most simple solution for every problem. It’s often misinterpreted to mean the first solution that comes into your mind. But the simplest solution to any problem can be the most difficult to invent. Now, if you accept the first solution, or the one that your customer already has, a good probability is that the simplest solution is never found. And you may work very hard to implement something that wouldn’t be needed at all.
IT has many things like – I have a solution bring me a problem. Workflow is one of those …
Mike/Bunny