"That (expletive) support!"

06 December 2006

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.

8 comment(s)
Greg Shelton
I haven't had this problem with Developer Express support, but I have been exposed to the "sample project first" support with some other vendors.  I understand why you would want a sample project and how important that can be to resolving the problem.  I *think* where most end-users get upset, including myself, is when you provide a support rep a reasonable number of steps to reproduce the problem and they ask for a sample project anyway.  I've run across these lazy support reps before and it can be really annoying --- especially when you're on open issue number seven.  Working in the healthcare industry, I have to work extra hard at removing sensitive patient information from test databases before I can submit these test projects.

If the support team receives a well described issue, that the end-user believes they should be able to reproduce, then the support reps should first try and recreate the problem with their own sample project.  After that fails, then ask for a sample project.


6 December, 2006
Luc Debrun
I have only praises for support. It feel like I have a team of programmers behind me. (Thank you Andrew and Plato for your support just over the last 2 days).

I do feel stupid to ask such basic questions sometimes. I have made my point in the newsgroups that may be a little more time spent on docs with lines after lines of code and project samples would reduce your workload in support.

That would allow DevEX to distribute more resources for those people who need advanced support NOW because that their paycheck is on the line. (Mine isn't if I dont get a reply within 24 hours).

If I am allowed to veer slightly off topic, I would suggest that rather than 4 majors per year you do 3 majors only, but instead 1 major for the docs/year. It should be part of your $ incentives to your programmers that the docs and knowledge base are complete since that would reduce the cost of support you provide.

Luc
6 December, 2006
Bob
I think your support is excellent.  I personally don't mind providing sample apps at all. I completely understand (as I too am asked to fix issues from my customers).  It is sometimes a pain to reproduce a small enough app that we can give you that reproduces the problem, but the results are worth it.  When the sample is created, I am sure what I am seeing is incorrect behaviour, and your support team can give much more accurate answers.

Again.  My kudos to your support team.  They have been nothing but courteous and helpful whenever I have had an issue.
7 December, 2006
Doug Leadley
As a positive for your support, I am impressed with the fact that I can get a test build for resolved problem if I ask.  I also like the fact that patch builds for fixes come a regular intervals.  I use the ASP components is some complex methods, but I am pleased with the support for far.  Keep up the good work and...

ship 6.3.2 next week please :)
7 December, 2006
Scott Blood
Julian,

I read this post with great anticipation in the hope that you would touch on the fact that some of your customers, are not actually on the same time zone as yourself, i.e. i am on GMT.

One of my main gripes and problems is that if i get to a Monday afternoon, when we have scheduled an update to our software, either because of bugs or updates the customers have requested and then suddenly our UAT guys (User Acceptance Testing) report a last minute bug which turns out to be in a devexpress product, i usually have to wait upto 3 days for a reply and this isnt because your guys cant be bothered, its simply because of the time difference.

This is also the same for a support email sent on a Friday :( which we have now tried to prevent or reduce the number of updates being issued on a Friday, but because we are an online and high street betting company, our busiest time of the week is the weekend and sometimes its a necessity for the business that updates are released at the weekend.

I guess what i am trying to ask for is some kind of emergency help system, whether this be through a paid support line or a 24 hour on call emergency number which if abused you then obviously charge the customer, but if it is found to be a bug, maybe some advice or help can be given on the spot and the decision can then be made from a business prospective whether or not a release can go ahead.

Regards
7 December, 2006
Plato
Hi,

Let me add my 2 cents to this post as a member of the support team. We often receive messages similar to the following:  
 
I want to make a column in the XtraGrid invisible.  How can I do this?
 
At first glance, the problem can be easily solved and this support incident looks very simple.  However, such simple cases could be very dangerous.  In such cases, I could usually give the simple answer: that you should make the column's Visible property to false.  It is obvious and, if I were a developer who wrote this message, I would probably have checked this first.  So, it looks like this code does not work for him.  But we don't know why, as the original question contains minimal information.  So, perhaps, this code is being called from the wrong place, where the XtraGrid's API cannot process such a request properly.  
 
So I'd like to ask you to give us the context of your task.  We need it, not because we want to read long emails (in fact, we'd prefer not to :)), but because such information allows us to find a solution faster and prevent follow ups.  For example, in my case, the code  
 
Column.Visible = false;  
 
probably doesn't work and if we knew the context, perhaps we could be able to suggest an absolutely different approach which would use the control's functionality better and avoid the initial problem.  
 
with best regards,  
Plato  
 
P.S.  I do not remember problems with setting the column's Visible property in the XtraGrid (from my point of view, XtraGrid is an excellent control :), it was just the first example which came to mind).
7 December, 2006
Rollie Claro
i got no problems with support, as a developer myself, i understand what the term "support" means. some users can be annoying. they ask you questions like, where can i find the save button? sounds familiar? duh. but you know, truth is, we all encounter different problems. one might think that it is fairly easy to solve the problem, but lo! the software has for some reason did this btnSave.visible = false. so i guess plato is right.

  i should add, it is not the quantity of information you give but rather the quality.


thanks.

"develop a software that even the fool can use, and only a fool will use it"
7 December, 2006
ctodx

I thought I would just point out a few of my posts from the past -- raising them into your consciousness

18 June, 2008

Please login or register to post comments.