When you are looking for more information, it helps to say what you need the information for

It's often the case that when a question from a customer gets filtered through a customer liaison, some context gets lost. (I'm giving the customer the benefit of the doubt here and assuming that it's the customer liaison that removed the context rather than the customer who never provided it.) Consider the following request:

We would like to know more information about the method the shell uses to resolve shortcuts.

This is kind of a vague question. It's like asking "I'd like to know more about the anti-lock braking system in my car." There are any number of pieces of information that could be provided about the anti-lock braking system.

  • "It requires a Class C data bus."
  • "The tire position sensors are on the wheel-axis."
  • "It is connected to the brakes."
  • "It is shiny."

When we ask the customer, "Could you be more specific what type of information you are looking for?" the response is sometimes

We want to know everything.

This is not a helpful clarification. Do they want to start with Maxwell's Equations and build up from there?

As it happened, in the case of wanting more information about the method the shell uses to resolve shortcuts, they just wanted to know how to disable the search-based algorithm.

This sort of "ask for everything and figure it out later" phenomenon is quite common. I remember another customer who wanted to know "everything" about changing network passwords, and they wouldn't be any more specific than that, so we said, "Well, you can start with these documents, perhaps paying particular attention to this one, but if they tell us what they are going to be doing with the information, we can help steer them to the specific parts that will be most useful to them."

As it turned out, all the customer really wanted to know was "When users change their password, is the new password encrypted on the wire?"

Third example, and then I'll stop. Another customer wanted to know everything about how Explorer takes information from the file system and displays it in an Explorer window. After asking a series of questions, we eventually figured out that they in fact didn't want or need a walkthrough of the entire code path that puts results in the Explorer window. The customer simply wanted to know why two specific folders show up in their Explorer window with names that didn't match the file system name.

When you ask for more information, explain what you need the information for, or at least be more specific what kind of "more information" you need. That way, you save everybody lots of time. The people answering your question don't waste their time gathering information you don't need (and gathering that information can be quite time-consuming), and you don't waste your time sifting through all the information you don't want.

You might say that these people are employing the for-if anti-pattern:

foreach (document d in GetAllPossibleDocumentation())
 if (d.Topic == "password encryption on the wire") return d;
Comments (46)
  1. Christian says:

    I would like to know more information about Windows. ;-)

  2. John says:

    Would you like to know more?  The only good bug is a dead bug!

  3. Simon Farnsworth says:

    Note also that if you don't know what you want to know, a good question would be something like "I would like to know how the shell resolves shortcuts. In my system, I have temporary documents created that contain interesting data about the state of the operation from the user's perspective. If the operation succeeds, I rename them to act as audit logs. I want to install shortcuts to the latest version of the temporary documents, so that users can inspect them in the event of failure, but for some reason, users keep seeing some of the audit log versions."

  4. plio says:

    int LifeUniverseEverything()  {return 42;}

  5. JB says:

    I think your final anti-pattern is wrong, it looks like a simple linear search. If it said "return d.Topic" it would be your pattern :)

  6. Aaron.E says:

    I don't think that code sample quite captures the scenario.  It's more like:

    Document documentCustomerWants = null;

    foreach (Document d in GetAllDocuments())


       if (d.Topic == "topic customer wants")


           documentCustomerWants = d;



    return documentCustomerWants;

  7. Joshua says:

    Under the assumption the documentation actually exists internally, it may or may not be cheaper to just send it. If it were properly annotated as to what parts may change it would prove actually useful. This is already constrained by backwards and forwards compatibility.

  8. DWalker says:

    I like starting every discussion from Maxwell's equations.  Or, we could start with a discussion of how electrons move through semiconductors.  We could even break the electrons down into their constituent parts, and bring in the various theories of quantum mechanics, if we are so inclined.  From a discussion of quantum mechanics, it's an easy jump to bring in philosophy.  

    Eventually, we'll get back to semiconductor design, and the history of microprocessors, and how operating system code gets translated into machine language, and then specific operating systems such as Windows, and then …

  9. arousedboat says:

    Sometimes it works the other way.

    My friend was at the home improvement mega-store and asked someone in the tool department, "Where can I find a 1 inch hole saw?" The man looked puzzled and then responded, "Well, what do you need it for?" "Making a 1 inch hole."

  10. jader3rd says:

    I hate having folder names different in explorer than on the file system. The first thing I do after getting a new machine is deleting all of the LocalizedResourceName's from the desktop.ini files. And it really bugs me when a Windows update puts them back.

    [You're really lucky that your preferred language is English, then. -Raymond]
  11. Mason Wheeler says:

    @Arousedboat: That's still useful information.  Then you can take him to the appropriate aisle and sell him a drill with a particularly large bit.

  12. Jimmy says:

    @arousedboat: The guy could easily have meant: "What material are you cutting with it" rather than "what does a 1 inch hole saw do"

  13. Leo Davidson says:

    Asking for everything might make sense if you're paying per request rather than per time, difficulty or volume of information.

    (Well, might if there was any chance of actually getting everything, which there usually isn't.)

  14. alegr1 says:

    There is name for that: "special needs customers".

  15. cron22 says:

    You know, I hate to tell you, but the explorer example was kind of a bad one, for now I'm curious myself.  

  16. John says:

    @jader3rd:  I used to be the same way (not specifically with desktop.ini, but in general).  After a while you realize it's just not worth the effort; it's easier to go along with the system rather than fight it.

  17. Matt says:

    Stop thinking like a programmer, and think like a human.  Obviously, explain anything you find as unique to the anti-lock breaking system as has to do with it's main purpose… then tangentially explain things as appropriate.  This type of black and white thinking is why programmers can't speak to normal people.

  18. @Matt says:

    And that's why they usually don't. Its not worth your programmers time to shoot the breeze with a customer, that's what front line support/documentation is for. After the customer has proven that they've got a basic understanding of the concepts and have a more directed question, at that point, and that point only, waste the programmers time. Until then read the manual.

    However in most cases the customer can't be bothered to read the docs, and instead wishes to be spoon fed.

  19. chentiangemalc says:

    I'm glad I'm not the only person in the world dealing with this. Although what I hate even more is when people outright lie when requesting more information, I cannot figure out how this benefits them. I'm often providing IT support to "IT Support" people and some conversations have gone like this:

    "The PC logon is slow"

    "Is it connected to Wi-Fi?"


    "So it's on the LAN?"


    "Did you check?"


    "Are you sure"


    "Do you want to go and check again?"

    "Yeah checked"

    "That was pretty fast did you really check?"

    "I know it's on the LAN"

    "So you didn't check?"

    "It should be on the LAN"

    "GO CHECK"

    "Oh yeah the machine is on Wi-Fi. I thought it was on the LAN"

    From experience unfortunately I'm developing a cynical scepticism of whatever people tell me about a problem. I need evidence to believe. :)

  20. alegr1 says:


    But why the logon is slow on the WiFi?

  21. Aaron.E says:


    That's why most support people ask the customer to do something like "reset the network cable."  It's an instruction designed to force the customer to realize their mistake.

  22. Joshua says:

    [… "How does Explorer get the icon from the file system", that involves digging up the documentation for all shell namespace extensions and shell icon handlers (most of which were not written by the shell team)…. -Raymond]

    Amazing coincidence. This has come up for me a few times in the past (I don't currently need an answer), each time with a twist. The limiting filter was always "It's a filesystem like entity", with sometimes the additional filter of "You can't read the datastream for the file [as a cheap operation]".

  23. 640k says:

    [You're really lucky that your preferred language is English, then. -Raymond]

    Also known as THE invariant language.

  24. Hat Off says:

    ["How does Explorer get the icon from the file system"?]

    Yeah… about that… we have this back door into the kernel… undocumented… because it's so hard to document…

  25. chentiangemalc says:

    @alegr1 The logon for Wi-Fi is slow because domain network with logon scripts at a site where too many laptop users per Wi-Fi hotspots

    @Aaron.E – exactly right. still kind of amazes me it's necessary, but it is.

  26. cheong00 says:

    I'll add note that in MS forum, many times we see people ask questions broad as that, and these questions are destinated to be ignored most of the time.

    It's not likely helpers there is willing to write a 3-hour length article to answer apparently lazy questions.

    However, in case of paid support, I'd expect them to be served better. You can ask them to provide backgrounds of the problem to narrow it down yourself. Actually you may influence the system ticket system to ask the first line support leave background information of the question in order to improve utilization of non-first-line supporter's time. (Emmm… I tried to mix some bizzwords there but seems not quite enough… //think)

  27. spork says:

    Kind of unfair to assume the requestor is *always* a dummy for asking open-ended questions.   I can see Raymond's point of view– if he has more context, then he can focus on providing heightened relevence in the answer.  Absolutely makes sense.  But me personally, as a requester, sometimes I really prefer to get firehosed with info and filter it myself– that is a feature to me, not a bug.  

    [You're assuming that the documents already exist and can just be handed to you. In many cases, there is no customer-ready documentation to be handed over. So there's an implied step "Spend a few weeks writing customer-ready documentation." There's also an implied ste "Gather all the relevant documents" — for something as broad as "How does Explorer get the icon from the file system", that involves digging up the documentation for all shell namespace extensions and shell icon handlers (most of which were not written by the shell team). And it's a waste to spend all that time writing documentation that the customer will never read. -Raymond]
  28. TC says:

    This happens when the wrong people are allowed to ask questions! If I had an MS support contract, I'd filter everyone's questions through someone who knew how to ask them properly. Clearly many customers don't bother to do that.

  29. Scott says:

    They ask for everything because they're afraid of this:

    Q: Is the password encrypted over the wire?

    A: Of course! (Note to self: check and make sure it is)

    By asking for everything, they're looking for the chance to find that in step 83 it actually isn't encrypted.

  30. ender says:

    [You're really lucky that your preferred language is English, then. -Raymond]

    My preferred language is Slovenian, but I loathe what's been done to Program Files. I've been using Vista since 2007, and I still get WTF moments when I forget that Explorer is lying to me about what's on disk.

  31. Wound says:

    I've learnt that almost whenever someone asks me for something odd, the correct response is "why do you want that?" 90% of the time they're trying to solve some problem starting from the little bit of knowledge they have, but are totally unaware that the correct solution to their problem is totally different (and much simpler)

  32. TejasJ says:

    @TC – Agreed.

  33. SI says:

    @DWalker: electrons are leptons, they dont have constitute parts (unlike protons/neutrons).

  34. Simon Farnsworth says:


    There's another way to ask the same question that should get the answer you need, though:

    "Under what circumstances will the password go over the wire unencrypted? In particular, is there any way for a client to force the server to accept a plain text password, given a server that wants an encrypted password? Also, is there any way for a server to force the client to send a plain-text password, even when the client would prefer to encrypt it?"

    You've now given the documentation team areas to look at – can the protocol be abused to force plain-text, or is this something that has to be explicitly configured at both ends?

  35. John C. Kirk says:

    The comment about Maxwell's equations reminds me of one of my favourite Dilbert strips:


    "Early civilizations had no concept of zero."

  36. DWalker says:

    @SI:  I thought electrons were made of tiny vibrating strings, per string theory.  Talk about first principles!

  37. jader3rd says:

    "You're really lucky that your preferred language is English, then. -Raymond"

    I don't see how wanting to see the same thing when navigating in the commandline as navigating in Explorer to be language dependent.

    [<>So German users should be thankful that they have to click "Calculator" and "My Documents" instead of "Rechner" and "Eigene Dateien"? "Thank goodness my icons have the same names that the command line shows. I mean, sure it means I can't use the computer in my native language, but it keeps the CLI nerds happy!" -Raymond]
  38. Random832 says:

    [So German users should be thankful that they have to click "Calculator" and "My Documents" instead of "Rechner" and "Eigene Dateien"?] — Why not have the files actually called that? "calc.exe" isn't visible to the casual user, and… erm… the lack of a method to programmatically get the location of the My Documents folder is a shocking oversight.

    [So you're saying that all users of a computer must have the same preferred language. Interesting requirement. My sister-in-law might not like it, though, since her preferred language is Chinese. (And I don't know what you mean by the second remark. SHGetSpecialFolderLocation has been around since 1995.) -Raymond]
  39. @jader3rd

    Just to be picky here, there are slight differences between what is shown to the users and what the directory name is even on the English version.

    In explorer on Win7, your profile has the folders name My Documents, My Music, My Pictures and My Videos. Under the command prompt these are named Documents, Music, Pictures, and Videos. So it is like that even on English versions of Windows, so adapt.


    Because if you take an English copy of Windows 7 Ultimate, install the German MUI and then remove the English MUI, what you have left over is pretty much identical to what you would have if you installed the German version of Windows 7 Ultimate. You see, the core part of Windows itself has been language independent since Windows Vista, but for this to work file names need to be invariant across versions. The beauty of the current layout of Windows is that it is so easy to just swap the language packs, and doing what you suggest would cause major issues.

    Lets suppose that you have two language packs installed. Now what name would calc.exe be then, would you rename it to the current language settings? That would be hard because the UI language is a session setting, so two users could be logged on at the same time with two different UI languages, and what is even better, none of these logged on users have to have the same UI language as the system default. So if the file name is dependent of the UI language, which would it choose here, because you could guarantee that no matter what you choose, calculator will not work for someone. Well, you could use hard links to link these files to the original, but that would just waste disk space (since each link is an extra entry in the MFT).

  40. Danny says:

    @DWalker "Or, we could start with a discussion of how electrons move through semiconductors".

    You forget to branch your discussion here for PNP / NPN ;)

  41. ErikF says:

    @Randon832: Imagine if that actually happened. How would you be able to write programs that call system utilities, particularly in a multilingual environment? Let's say that I have a program that calls notepad.exe to show the contents of a file to a user (or does anything that calls a system utility, name your example) In a Greek system, it's not notepad.exe but μπλοκ.exe. Surprise! Better yet, imagine the fun that support techs would have in tracking down programs!

    I can't think of *any* OS that has language-variant system locations; certainly Unix doesn't, and it's usually the OS that people like to show as a counter-example to anything that Windows does.

  42. Joshua says:

    In *nix, the start menu items aren't filesystem objects.

  43. kinokijuf says:

    I’m surprised you didn’t link to blogs.msdn.com/…/71307.aspx

  44. kinokijuf says:

    oops, wrong link.

  45. GWO says:

    @Joshua Depending on that flavour of *nix you're using, menu items can absolutely be filesystem objects.  Gnome and KDE both allow you to use .desktop files to define app shortcuts, and these can expose LOCALE dependent icons and names to the GUI shell.

  46. Jim says:

    I strongly agree with Scott's idea of why a user might do this: to guarantee (at least maximise the chances) of an accurate reply. A slight variation is that, even if you basically know the answer, you might not know or might choose to omit a small detail that could turn out to be important. ("If I mention that passwords aren't encrypted in this odd situation, it'll only confuse them…")

    Also, filtering through documentation ourselves is what we're used to doing, as a result of usually researching things using search engines rather than asking people. This is a cause of both Scott's point (don't trust direct answers) and Raymond's (can't be bothered to pose the correct question).

    And you never know but perhaps the user is actually trying to save you time by hoping for preexisting documentation rather than making you think about the answer for yourself! But it's easy for me to be that uncynical when I don't get queries like this :-)

Comments are closed.

Skip to main content