| Date: | March 23, 2006 / year-entry #106 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060323-00/?p=31803 |
| Comments: | 21 |
| Summary: | A common obstacle when trying to help people solve their problems is that what people ask for and what they actually want are not always the same thing. For technical problems, you often get a question that makes you shake your head in disbelief, but upon closer questioning, you find that the person really doesn't... |
A common obstacle when trying to help people solve their problems is that what people ask for and what they actually want are not always the same thing. For technical problems, you often get a question that makes you shake your head in disbelief, but upon closer questioning, you find that the person really doesn't want what they're asking for. What they really want is something else, but they've already "solved" half of the problem and only need your help with the other half—the half that doesn't make any sense. For example, the literal answer to "How do I write a regular expression that matches everything except XYZ" is often a horrible mess, but if you dig deeper, you'll find that they really don't need a regular expression that matches everything except XYZ; they just simplified their problem to "I know, I'll use regular expressions" and ended up creating a bigger problem. (The best solution is often a mix of regular expressions and simple program logic.) This problem also exists in user interface design. Rick Schaut describes one case where a user asked for a feature, when what they really wanted was an entirely different feature. Understanding the customer's problem is the first step towards solving it. |
Comments (21)
Comments are closed. |
You really hit the nail there.
I wish I had a dollar for everytime a client asked for a specific solution (or tried to describe their problem with a technical solution).
You learn pretty quickly–after implementing a solutions based on what the stakeholder asked for only to be told that’s not what they need once they get the solution–that you can’t trust what they ask for is what they need.
The real art lies in trying to elicit what they truly want and trying to communicate that without coming across as unresponsive, or even arrogant.
That’s just human behaviour, and it’s not limited to ‘users’. Developers get it too – I can’t imagine how many times over the last couple of decades that I’ve answered the following question:
"How do I disable the Nagle algorithm?"
The correct answer is:
"You don’t – you fix your code so that the Nagle algorithm is not a problem. If your program is affected by the Nagle algorithm, either it, or the protocol it is implementing, is broken. Possibly both."
This is why many developers answer every question with another question. This second question is designed to elicit the zeroth question – the question the original questioner had in mind when they thought that the answer to the first question would be the solution.
People should be forced to live with what they ask for if they are too stupid to figure out what they really want.
I’m reminded of a similar conversation some months back – yes, brads are the best nails for balsa wood.
Er… Alun… I can see plenty of reasons for disabling the Nagle algorithm. It does require, however, that you know what you’re doing, and why the algorithm exists before you make that choice.
For example, one of the bigger reasons it exists is to reduce packet flowthrough when people are sending single byte packets during telnet sessions. However, it hampers streaming of data. If you design your application so that you’re sending maximal data with each packet, it very quickly becomes a hinderance, not a help.
Maybe you’re thinking of window sizing instead?
Alun Jones: I disagree strongly on this one. Some games (such as Diablo 2, WarCraft 3 and World Of Warcraft), VoIP apps (Ventrilo), interactive apps (telnet, ssh, remote desktop / VNC) use TCP/IP, and either you disable Nagle, or things are going to suck no matter what (unless there’s a very low RTT AND the server "responds" to every command ala console echo).
Sure, the games and VoIP apps should probably have used UDP, but for stuff like telnet, it would be overkill (and generally work worse than a good TCP stack), and TCP w/o Nagle is exactly what you want here.
Bulk transfers –> TCP
Interactive, hitch tolerant –> TCP without Nagle
Interactive, hitch intolerant –> UDP
("Interactive" as in "every time I press a key something happens")
No? :)
I’ve run into this sort of thing many times.
I recall a few phone calls from a certain zealous gentleman who had errantly been given the developers’ phone line for our product. He had a million recommendations for ways we could improve our product, all of which would have created larger problems, or not actually solved the underlying problem. Eventually, we had to get the salesman who gave the man our phone number to get the person off our back, as it was very disruptive.
These days, I generally ask ‘what is the problem we’re trying to solve’ rather than ‘how do we do what the customer wants’.
This is not easy, though. Often, people can’t articulate their problems very well. It’s kind of like a child who is sick; they haven’t developed the language needed to describe in what way they’re sick, they just know that they don’t feel very well, because something hurts. Trying to get at what hurts so you can figure out how to fix it involves asking a lot of sometimes weird questions.
Besides what they *ask for* and what they *want*, there is also what they *need*. And these are three different things.
> The real art lies in trying to elicit what they truly want and trying to communicate that without coming across as unresponsive, or even arrogant.
> Besides what they *ask for* and what they *want*, there is also what they *need*. And these are three different things.
In my shop, we call the above "Requirements Mining".
Phil:
I don’t know if you’ve read it, but that really reminds me of a blog entry "Pounding a nail: old shoe or glass bottle" http://weblogs.asp.net/alex_papadimoulis/archive/2005/05/25/408925.aspx that I read the other day.
Of course, now I think of it, it’s what Raymond’s talking about too, but for some reason your post bought it to mind.
Windows Explorer missed several Huge usability features… Anyway,
1. Multiple file renaming with advanced renaming features (replace beginning, insert before extension 3 digits etc)
1a. Commenting files and folders with short notes/tags (perhaps shown in common tasks).
2. A simple switch to create two windows, one alongside the other, vertically split.
3. Custom, configurable common tasks, for example, one sub-context could contain shortcuts to user-defined folders. Suffers from too much duplicate functionality and a heap of wasted, upon wasted space.
4. More folder icons to distinguish folders better.
Off the top of my head. :)
Yes, discovering and documenting what is needed by the business produces an artifact called the Requirements.
The discipline for producing this artifact is Business Analysis, performed by Business Analysts; see http://www.iiba.com for more on this discipline and its role in Information Systems Development and Maintenance.
That’s why whenever I get a bug report, I run it throught the Joel Bug Algorithm (http://www.joelonsoftware.com/articles/fog0000000029.html).
Once I started requiring that for every bug assigned to me, I realized that most people’s tendencies are try to submit solutions, not problems. It’s taken years of simply playing dumb, and asking for each of the three parts when they are missing. Other folks are starting to finally catch on, and submit them like that in the first place.
The same thing happens to me with new UI design. Any time a user suggests something, I invariably have to ask "what are you trying to do"? Most of the time there exists a solution for what they want, but for some reason they can’t or won’t use it. When they tell me WHY, that’s the golden bit of information. Most of the time I can come up with something way better than the literal thing they asked for that solves their problem, and fixes 20 other problems that have been around for a long time.
What the result of not doing this? The best quote is one of our customers, after a major project: "It does everything we asked for, but nothing we need." Keeping your head in the sand and waiting for them to produce perfectly formed and unambiguous comments is a disaster waiting to happen. Take your customers too literally and it will be junk. They don’t know how to design software or UIs. They DO know what their problem is and why your software isn’t working for it.
To address those people that believe I’ve got my Nagles in a twist:
1. If your app can’t wait for the data, then it has to discard data that is too old. Ergo, it will benefit from UDP with a little reliability, rather than from TCP with a boat-load. So, yes, those apps that you describe should have used UDP.
2. In a telnet session, you’re asking that the person expect his keystrokes to appear immediately after a round-trip faster than 1/5th of a second (the Nagle / delayed-ACK delay)… If you type fast enough that this is of benefit, the Nagle algorithm will actually help, rather than hinder, your communication with the computer.
3. Streaming data… Uh… if you do as you say, and fill the buffer with every send, Nagle does nothing to your data, and enabling or disabling Nagle makes no difference. If Nagle sees a full buffer ready to go, it sends it. Nagle only holds up partially-filled buffers waiting for more data or an acknowledgement of previous partially-filled buffers. If disabling Nagle makes your streaming go faster, you’re not filling the buffers like you think.
PingBack from http://bossanovas.wordpress.com/2006/03/24/links-for-2006-03-25/
Our customers, sales, and even developers have asked me to add features for our products. But for most of the time, what I should do is communication, showing how we can solve the actual problems they encountered.
Yes, what they asked is not always what they want. And what they want is not always what they actually need.
Adam: Thanks for that link. This is the entry I was thinking of:
http://blogs.msdn.com/rflaming/archive/2005/10/01/476154.aspx
No, you don’t do that.
If you want multiple files, then drag multiple objects.
You can ask for its description ID.