Windows Confidential: Rationale is highly overrated
If you encounter something puzzling with a product, make the productive choice in how you respond.
Raymond Chen
Asking about the rationale behind how something works doesn’t solve anything. It might have just ended up that way. Any piece of software, from the simple to the complex, encompasses countless developmental details. Sometimes those details take the form of arbitrary choices.
Consider, for example, a command that accepts two parameters such as a user name and file name. If you happen to pass an invalid user name and an invalid file name, it’s a toss-up as to which one will be reported as an error. If the code happens to verify the user name first, then you’ll probably get an “Invalid user name” error.
What’s the rationale for choosing to verify the user name before the file name? There probably isn’t one. It’s just how things happened to have been written. It could just as easily have been written the other way around.
We’ll occasionally receive a request from a customer who observes a certain behavior like this. If they find it confusing or unwanted, they’ll ask, “What’s the rationale for this behavior?”
As software engineers, you already understand that a particular behavior could exist for any number of reasons. It could be a code defect. It could be a design oversight. It could be something the engineering team wanted to do differently, but couldn’t for reasons of time, resources, risk or priority. It could also be an intentional decision. Only if the behavior falls into that last category will there ever be a rationale.
When it’s done, it’s done
Once a product has shipped, any distinction of reason or rationale is largely irrelevant. The product behaves as it does. You can ask for changes in future versions, but the current version is a done deal. An explanation of why the product behaves the way it does (if such an explanation even exists) doesn’t change the product or its behavior. All it might do is mollify (or even enrage) you. It answers a question, but doesn’t solve a problem.
In many cases, there’s more to it when a customer asks the question, “What is the rationale for this behavior?” More often than not, it’s really just shorthand for, “I ran into some behavior that I didn’t expect and it frustrated me.”
Stating that you found a particular behavior frustrating is far more useful than simply asking for the rationale behind that behavior. It’s even more useful if you describe the situation that led to discovering the confusing or unwanted behavior that frustrated you. That feedback might clarify a design oversight or draw attention to a code defect. It might even convince the engineering team to alter their priorities to devote additional resources to addressing that particular problem in the future.
Asking for the rationale behind an issue carries the presumption that every issue should be addressed unless there’s an important reason to do otherwise. That’s just not how business decisions are made. Any change to an existing product needs to balance the risk, benefit, cost and priority of making the change.
What’s the rationale for the screen origin being at the upper-left corner of the monitor? What’s the rationale for not allowing you to write \\server\..\otherserver\share? Whether the answer is a carefully reasoned explanation or something like, “Because I was sleepy,” really doesn’t matter. You’re still experiencing your problem.
Response required
It’s cheap and easy to ask a question, but it puts the burden of expensive polite answers on other people. And those people have to guess whether your question is a passive-aggressive feature request or merely idle curiosity.
In either case, it can take an enormous amount of time and effort to research the problem. Someone will have to dig into the archives, and find people familiar with the original intent of the feature who remember the results of the usability studies or compatibility investigations (which can be quite a challenge for features that are several years old). This could all turn out to be wasted effort because none of that information is really what you wanted in the first place.
It’s far more clear and useful to explain the issue you found and the scenario that led to it so your request for a change in behavior can be better understood. Otherwise, your request for an explanation of the thought process that went into a particular behavior can come across as a nitpicky question that will make people wonder if it’ll even be worth the effort of responding.
.jpg "Raymond Chen")
Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming and crowd-sourced dream analysis.