Dotmad.net

Joel Spolsky wrote about customer service, and he mentioned a trick from Raymond Chen’s Old New Thing:

Sometimes you’re on the phone with somebody and you suspect that the problem is something as simple as forgetting to plug it in, or that the cable was plugged into the wrong port.
This is easy to do with those PS/2 connectors that fit both a keyboard and a mouse plug, or with network cables that can fit both into the upstream and downstream ports on a router.
Here’s the trick: Don’t ask “Are you sure it’s plugged in correctly?”
If you do this, they will get all insulted and say indignantly, “Of course it is! Do I look like an idiot?” without actually checking.
Instead, say “Okay, sometimes the connection gets a little dusty and the connection gets weak. Could you unplug the connector, blow into it to get the dust out, then plug it back in?”
They will then crawl under the desk, find that they forgot to plug it in (or plugged it into the wrong port), blow out the dust, plug it in, and reply, “Um, yeah, that fixed it, thanks.”
Customer saves face, you close a support case, everybody wins.
Corollary: Instead of asking “Are you sure it’s turned on?”, ask them to turn it off and back on.

I think most people with technical expertise remember simple problems like this:
“The printer is not working!”
“Can you check it’s on?”
“Oops”

However, Jay Young posted his thought on the subject:

The problem is though, it’s a lie. We all might think that there’s some understood language happening that says you know that their keyboard is unplugged, and they know you know. But I’m not so sure anymore. Maybe about the simple binary issue of a keyboard plugged in or not or XYZ setting turned on or off in the software - but not about more complex issues about browser settings and add-ons, interactions between software applications, or “just how exactly are you trying to print that again?”
What I’ve seen over and over again is that the crackpot IT lies become truths, passed around either from customer to customer, or even worse, by front-line support staff because they don’t understand your products and services either and the developers/systems people just lied to them about what was wrong and what the solution was.
Those wrong answers pervade a long, long, time. And they often prevent the real triage from occurring. That is, they often forestall Joel’s very, very, excellent first point - “treat each support call like the NTSB treats airliner crashes”. All too often, both product support and the customer completely give up when the problem goes away. (It might not be that’s it’s unplugged, you might have had a quality control issue on those connectors, and “blowing the dust out” masks the real problem).

I think you need to walk a thin line between actually lying (”Okay, sometimes the connection gets a little dusty and the connection gets weak“) and phrasing your request in a way the customer will be offended by it (”Are you sure it’s plugged in correctly?”).
You could say something like “Could you please unplug the connector and plug it back in?”.

And the more complex the problem is, the less you need to use subterfuge in order to have the customer’s cooperation.

David Betz has updated his great demo for testing the speed of various WCF channels.

I appear to still be having some problems with the forwarding from this domain to blogger, I hope I’ll be able to solve them soon.

After you decided to use Team system to automate your build process there is the possibility the build-in tasks will not be enough for you, and you will create custom tasks, to be executed during the build.

However, once the build is running and each phase is displayed in the build window, your tasks will not appear there.

I have written a new class which “CreateStep” and “CloseStep” methods, used to add a row for the task in the build window.

Instead of inheriting from “Task“, switch to “BuildStepTask“, and call “CreateStep” at the beginning of your task code and “CloseStep” at the end.

The class requires several parameters to link with the build server and retrieve a connection to the specific build being performed.

The “CreateStep” method uses those parameters to get a “BuildStore” object, and uses it to write to the screen. The “CloseStep” method is called once the task is complete.

public class BuildStepTask : Task
{
protected string buildUri;
protected string buildStepName;
protected BuildStore buildStore;
private bool abort = false;
private string buildNumber;
private string projectName;
private string serverName;

[Required]
protected string ServerName
{
get { return serverName; }
set { serverName = value; }
}

[Required]
protected string ProjectName
{
get { return projectName; }
set { projectName = value; }
}

An article with this name was published, detailing all the wonders of Vista, but actually describing .Net Framework 3.0 (especially WPF).
This is all fine, but what prevents me from installing the framework on Windows XP and skipping Vista?
As far as I can tell at this point in time, the only new thing Vista is offering is the developement of gadgets….

Jeff Atwood posted two very helpfull articles:
The first deals with increasing the speed of the build process by turning off few default behaviours.
The second shows how to add additional info to the build log file.

In a previous post I explained how to edit one of the Team system’s global lists, specifically the builds list.
As it turns out, there is a tool that can save you the hassle of doing this manually, and you can find it here.