"That (expletive) support!"

Every now and then, I get to talk to a customer about support, specifically an issue for which they've had to use our support facilities. For multiple reasons, sometimes those interactions are not as good as the customer or the support team or I would like, and I get in contact with the customer to investigate to see whether we can learn anything and become better at our support. I had occasion recently to write a longish email to one of our customers about how we do support and, specifically, how we'll sometimes ask for a sample program that reproduces the customer's problem. I thought I'd generalize it a little and post it here.

(A quick note: in this post I'm not going to talk about what we're discussing with regard to increasing our support options, such as the possibility of paid, premium, or phone support — the three Ps of tech support — because we're nowhere near ready to make any announcement about whether we are or are not going to do anything about it. So please don't ask :-).)

Although some of the issues that are reported to the support team are of the "duh, that's obvious, why didn't we catch it?" variety (necessitating some soul-searching about the depth of our testing, with me tapping my foot and glaring :-) ), a lot quite simply are not. For the latter type, sometimes we have published workarounds in our knowledgebase, but it seems fairly apparent that the issues could be due to one or more of the following:

• The customer's environment. This could be the operating system, the video driver, the IDE, etc. What's special about it versus the systems we use for development or testing?
• Bad interaction with other controls on the form. These could be our own controls — maybe we didn't test a particular combination — or other vendors' controls — in which case, we'll do our best to investigate. (The most funny, in a peculiar rather than ha-ha sense, was the recent report that our grid wasn't working with this free control that the customer had downloaded. It turned out that the control was a pirated rip-off of one of our other controls and had a bug we'd already fixed.)
• Some workflow with our controls that we didn't envisage. Although we try to predict how our customers will use our controls, and our help and demo programs show how we expect (hope?) the controls to be used, our controls' very flexibility and customizability means that we can never really be sure that we've tried every possible combination. Actually I think we should employ some of our customers as testers: they have a great propensity to do things like switch database connections in a display event handler. (Only joking!)
• The database engine. Perhaps the customer is using a database engine we don't regularly test with or have never used. In this case we can approach the database engine vendor to get a test copy -- we have done this many times in the past and are doing it right now with a couple of vendors (our XPO product tends to, er, exercise database engines quite thoroughly, shall we say). This actually works both ways: some database vendors ask us for a copy of such-and-such a control because they have a customer with a problem ("it works with SQL Server, but not with your database") and they want to solve it.

Some of these scenarios we can certainly investigate when we get a bug report (which is why we ask for a lot of ancillary information as part of the report), but for some of them we simply have no other alternative but to ask the customer to help us isolate the issue. That's when we'll ask for a sample test program with code (and a sample database, if needed) that shows the problem. In rare cases, we'll even ask, if that initial request doesn't expose the issue and if the customer is willing, for the customer's actual project.

We certainly don't do any of this to annoy or brush off the customer ("heh, he'll never do it, so we can close the issue, gimme five!"), we ask because we want to find and fix the problem. Sometimes the simplest way to find a bug is just to trace through the code in a debugger. We have found, through many such requests, that this approach helps both our support people and the customer to resolve the issue most of the time and definitely as quickly as possible.

Sometimes, even the very act of writing a simple application to show up a bug reveals the problem immediately, and it becomes a "duh, that's obvious, why didn't we catch it" bug (cue more foot-tapping and glaring). Many times a sample project enables us to provide a workaround or make some suggestions for the customer as we schedule the bug to be fixed or the knowledgebase to be updated. Sometimes a sample project enables us to regretfully say that our product simply can't do what the customer wants, the famous "it's working as designed" resolution.

I must say that I'm proud of our support and proud of the support team. I feel that our support is a differentiator for our company. I'd have to say from my viewpoint the majority of support issues are handled well, with the customer able to continue working with our products at the end of the day, but as I said earlier, sometimes they're not and I get involved.

So please don't get upset if we ask you to help us fix the issue you found by providing a sample program. Principally, we're doing it to help you but, ultimately, doing so helps all our customers by enabling us to provide better products.

Free DevExpress Products - Get Your Copy Today