|
|
Why is it so much more difficult to debug problems occurring on remote customer computers than on your own computer? For one thing, you probably won't be able to use all your debugging tools to analyze a customer's computer. Visual Studio .NET contains a pretty fair remote debugger, which we'll discuss in more detail later. But unfortunately, it has limitations that usually prevent its use with most remote customers. You will seldom be able to repeatedly step through the code on a customer's computer the way you can with code on your own machine. Debugging customer issues means giving up your single most powerful debugging tool from the very start.
But jumping into the debugger shouldn't be your first instinct anyway. The next problem with diagnosing customer issues is that customers are often careless about providing exact repro steps: "Yeah, I clicked on some button—I don't remember which one—and then it showed an error message that said something about a failure, but I don't remember exactly what, and then the program crashed." Based on that description, good luck figuring out even where to begin looking for the bug. Asking the user additional questions about their setup will likely produce equally vague answers.
In fact, not only will customers give you vague information, they'll sometimes unknowingly give you flat-out wrong information. And if you ask them too many questions, they will become annoyed and even less helpful. It's not that your customers are stupid. It's just that many of them are non-technical and don't realize how important the specific details are to solving the bug.
Next, many of the reported bugs will turn out to be mere user error. "I saved a file with your word processor but the file is now gone, and I've lost all my work!!!!" You ask the customer if he's sure he's looking in the right directory, and he'll say, "Of course!" But the next day he'll sheepishly admit he had saved the file to a different directory, and that's where the file still is. User error can take all kinds of forms, and it can affect smart customers as well as dumb ones. Maybe the program works exactly as designed, but the user was merely expecting something different. Obviously, you can't fix a bug that isn't there. So unless you can recognize the problem as user error, you'll waste endless time trying to fix a phantom.
Then there's the infamous "DLL Hell," where installing one program suddenly breaks other programs that had been running fine before. This problem is especially bad with legacy COM components, and it's caused millions of headaches (plus a few lawsuits). Luckily, .NET goes a very long way towards reducing the problem, but this bug still comes up every now and then. Your software might be 100 percent bug free, but if a user installed some other program that broke yours in an unpredictable way, then it will be extremely difficult for you to figure that out without additional information. If this bug occurred in your test lab, you could selectively uninstall and reinstall all the programs until you figured out the problem— but that won't be an option with your customers’ computers.
Finally, don't forget configuration issues. This is where the real pain is. It's easy to write software that runs on a standard computer. The real trick is to handle a million and one special cases. Sure your code works for you, but will it work for that one customer who has special characters (~ : / | ? \) in her logon name? I had that bug once. Did you test your GUIs to make sure they work when Windows is set in Large Fonts mode? I had that bug once, too. Maybe your code expects Internet Explorer to be in the user's path (and it is by default), but one of your customers moved the Iexplorer.exe file to a different directory—will your code then show a helpful error description, or will it just crash?
Will your code work if the user has international settings turned on to use commas instead of dots for the decimal mark? Were you aware that Windows has a little known feature called Group Policy that lets administrators change over 300 kooky things such as automatically removing all non-default icons from the user's desktop? Did you verify that users are still able to run your program with each of those 300 different settings? If not, then your code will run fine for the majority of customers who don't have crazy configurations, but some percentage of your users will run into each of these problems.
If you get lucky, you might realize, based on the customer's description, that the issue is Group Policy (or whatever), and then you can set up the same configuration on your computer and debug the problem. But it's more likely that it won't occur to the customer to mention that he has a Group Policy object installed, and it won't occur to you to ask, either. Once you know the problem, then fixing it will be easy. But it may take quite some time to figure out what the problem is since you can't actually see the user's computer.
|
|