Good comedy takes some element of truth and stretches it to the absurd. However, the Dilbert cartoon series might not have to stretch the truth too far when showing the humor associated with providing (or receiving) technical support.</
Good comedy takes some element of truth and stretches it to the absurd. However, the Dilbert cartoon series might not have to stretch the truth too far when showing the humor associated with providing (or receiving) technical support.
In a recent Dilbert Zone cartoon, by Scott Adams, Pointy-Haired Boss approaches Tina, the brittle tech writer, and said, "You'll have to have all the documentation written by next week so we can ship it when the software is done." Tina replied, "How can I write instructions for something that doesn't exist yet?" Pointy-Haired Boss answered, "You'll have to make logical guesses." That ended the conversation between Tina and Pointy-Haired Boss, but the last caption of the cartoon showed Tina as she was writing the software documentation, "If you press any key your computer will lock up. If you call our Tech. Support, we'll blame Microsoft."
With all good humor, there's some element of truth to it. How often is software documentation written before the final product is completed? My guess is that, in reality, the software engineers and the technical writers probably work hand-in-hand while the product is being created. But how often is something overlooked? I've seen it happen. How often is something lost in the translation? I've seen that happen a lot. Does the technical writer ever have to make logical guesses, as suggested in the cartoon? In some cases, it might not be too much of a stretch to think so. Does software always behave as it's supposed to? Well, sometimes it doesn't — and it's not always user error.
I was recently involved in trying to figure out why one of our applications, Revit MEP, wasn't behaving as it was supposed to. In such cases, I always try to keep in mind that old adage "software (or a computer) won't do what you want it to do, but rather what you tell it to do," meaning that if the result you're seeing isn't the one you expect, then it must be something you've overlooked, or something you've configured incorrectly, or something else along those lines. This is where I might check, double-check, and even triple-check the settings and configurations, retrace the steps taken, and even duplicate what was done. After all, it can't be a bug in the software, can it?
In my particular case, without going into a lot of detail, Revit MEP, a building design software, wasn't showing building sections correctly, even though we did everything the way we were supposed to. Or were we? We were not really questioning the software, but rather questioning ourselves, wondering what it was we were overlooking. Since we haven't been using this product for too long, I called our vendor's tech support looking for an answer. Surely they would easily point out that little thing we were overlooking. The way we described the problem to the support tech didn't make a lot of sense to him, so we established a remote session and he took over the computer to check everything himself. Well, after an hour and a half of checking, he was just as stumped as we were — and still are. It should work, he said, but it doesn't.
I suppose this might illustrate another old adage about good news and bad news: the good news is we weren't overlooking anything obvious; the bad news is that it still doesn't work right, and we still don't have the answer. Another bit of good news is that the software manufacturer, Autodesk, will actually accept our project file and try to find out what's going on with it. But that comes with the bad news that the answer might not be discovered before our building design project is due.
User support (yours truly, in this case) might not always have an answer. Taking it to the next step, the vendor's tech. support, doesn't always provide an answer either. And the last step, the software manufacturer's engineers, might not even provide an answer; but the jury is still out on that one.
Help desks often follow written scripts based on how an application should work, but what if the user is faced with something out of the ordinary, and it's something not written in the script? Software might not always behave as it's supposed to; did a technical writer somewhere have to form a logical conclusion that might not have been correct?
Of course, when it comes to an application or some hardware not behaving as expected, it is indeed very easy to just blame Microsoft, just as Tina, the brittle technical writer did. That's something I've seen done, and I must admit, something I've even done myself. After all, who could possibly disagree with blaming Microsoft?