tele/scope
February 23, 1998
Norvin Leach
MSDN Online News Editor
We're posting a series of four articles today, called "Development Issues." In these articles, our MSDN developers discuss the problems and speed bumps they ran into during development of the HelpDesk sample, and explain how they worked around them.
At the same time, I'd like to share some of my own observations. Now, I didn't develop the HelpDesk sample. In fact, I didn't come into it until late in the game, when we were ready to post it as an online Feature. But still, there were some clear lessons from the posting.
I've written about this in a previous column, and it will probably hold true for all applications forever. Still, it bears repeating. Just as we writers believe that our sterling prose never needs editing, developers often believe that their code is bug-free. But that's impossible. There are just too many combinations of systems out there for any developer to be able to test every possible scenario.
For example, one HelpDesk user discovered that his SQL Server configuration only allowed 12 characters for login names. That meant that when he logged into the HelpDesk as Administrator (13 letters), the app didn't work. None of us at MSDN used that particular SQL Server configuration, so no one caught the bug.
Again, this doesn't mean that testing is a hopeless task. It means that you should never be fooled into thinking that your application is completely clean.
Upon reflection, I should have thought of this earlier. However, it wasn't until the first bug report arrived in e-mail that I realized we needed a good way to make users aware of fixes to the HelpDesk.
Now, the bugs didn't affect everyone. Furthermore, our developers were able to wipe out the bugs quickly and put up clean versions of the files. But we were getting thousands of hits on the page, which means that at least some people still needed to be alerted.
How could we do it?
That wasn't practical, though, and we didn't want to limit access to the HelpDesk.
When we launched the feature on Feb. 2, we added a mailto: link on the default page of the feature.
This link was meant for comments and questions, and at first, people used it for that. Very quickly, though, users started sending in other questions. They jumped on the opportunity to converse with a live person.
We got questions about any number of odd things, such as, "Why can't I fax from NT?"
This flood of tech-support questions is symptomatic of a problem that we see everywhere in the industry—not just at Microsoft: Tech Support is a sore spot.
Developers—in fact, all users—want better connections to tech support. They want live humans rather than voice mail. They don't want to waste time in triage.
At first, this may not seem relevant to your work (although you may have experienced some of these problems yourself).
If our research is correct, most developers don't provide tech support for their products. Some of you provide training. A few provide high-level support (answering the really hard questions). But only a small number of you actually provide support for the products you build.
Nonetheless, you all risk getting hit up with tech-support questions, wherever you are. If you post in a newsgroup, if you deliver a technical talk, chances are people are going to ask you tech-support questions. And there's even a chance that they'll ask you questions about completely unfamiliar topics.
It's kind of like meeting a doctor at a party. You often can't help but ask her about a medical problem. And when people find out I work for Microsoft, they ask me how to use Excel. Eventually, I guess, you get used to it.
Is there anything you want to ask us? Send us mail.