Software application development
This blog is intended to provoke discussion and exchange between like minded software application developers, engineers, architects, project managers - and keen hobbyists too.
Monday 6 October 2008, 7:26 AM
Things developers need to know before calling Tech Support
I’ve spent part of this weekend working on a tutorial with two chaps out in Denver Colorado that examines the mechanics of how they work with developers to help fix application errors. What makes this piece stand out is that the authors (Paul Vero & Wayne Smith) have taken the trouble to guide the reader through the typical scenarios and exchanges from their end of the phone line.
“Why don't you have the versions, the traces? Did you reboot?” … and also … “Have there been any changes made to your application or the server? Maybe changes to the data?” All the questions are in there and it’s nice to read a sympathetic account of what the developer will be hearing down one end of the phone line with the tech support guy actually explaining why he needs certain things.
It’s refreshingly honest to learn that when you are looking at an error and sitting there thinking just how could this get through testing? The reality is this: test suites include sections devoted to detecting regressions, but all possible combinations can’t be tested. There’s simply too much to possibly test for.
The central messages from this piece are that there is a reason why you are being asked for voluminous log and trace files and that, no matter how insignificant you may think it is, every tiny detail just might help tech support work out what the problem with your application is. Sometimes they even get a sniff of a ‘pattern’ just by looking at what may initially seem like reams of gibberish.
According to the Paul & Wayne, “TDS is the Tabular Data Stream protocol, which is what the client and server use to communicate. If there were only one thing a Tech Support Engineer could use to help understand a problem, the TDS trace would be it. You’ll probably hear Tech Support asking for this so many times, it’ll make you cringe in horror.”
It takes a REALLY good tutorial for any man to be dragged away from Top Gear on a Sunday night and work through something like this. But there you have it.
“Why don't you have the versions, the traces? Did you reboot?” … and also … “Have there been any changes made to your application or the server? Maybe changes to the data?” All the questions are in there and it’s nice to read a sympathetic account of what the developer will be hearing down one end of the phone line with the tech support guy actually explaining why he needs certain things.
It’s refreshingly honest to learn that when you are looking at an error and sitting there thinking just how could this get through testing? The reality is this: test suites include sections devoted to detecting regressions, but all possible combinations can’t be tested. There’s simply too much to possibly test for.
The central messages from this piece are that there is a reason why you are being asked for voluminous log and trace files and that, no matter how insignificant you may think it is, every tiny detail just might help tech support work out what the problem with your application is. Sometimes they even get a sniff of a ‘pattern’ just by looking at what may initially seem like reams of gibberish.
According to the Paul & Wayne, “TDS is the Tabular Data Stream protocol, which is what the client and server use to communicate. If there were only one thing a Tech Support Engineer could use to help understand a problem, the TDS trace would be it. You’ll probably hear Tech Support asking for this so many times, it’ll make you cringe in horror.”
It takes a REALLY good tutorial for any man to be dragged away from Top Gear on a Sunday night and work through something like this. But there you have it.
Previous
