Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!dptg!pegasus!psrc From: psrc@pegasus.ATT.COM (Paul S. R. Chisholm) Newsgroups: comp.software-eng Subject: Re: Are users stupid? Summary: my attempt Keywords: troubleshooting guides Message-ID: <4093@pegasus.ATT.COM> Date: 14 Sep 89 15:41:52 GMT Organization: AT&T Bell Laboratories Lines: 38 Somebody (I'm quoting another article, and the original attribution is lost) wrote: > Bad assumption. Not all users are stupid, but some really are - I seem > to remember a bug report at Sun for which the fix was "you know that > black thing coming out of the back of your machine? Try plugging it > into the socket on the wall." I've written a couple of administrator's guides (as well as the software they were documenting). I always tried to write them such that field support (and I!) would get a minimal number of calls. (One product is *just* out, and only to two customers. The other has been out for a year, has sold a few copies, and I've been able to answer at least one call with, "The answer to your question is on page 5-23, namely . . .") In fact, the chapter of the latter product labeled "Troubleshooting -- first steps" begins, "Start troubleshooting the same way you would troubleshoot a washing machine: make sure everything's plugged in!" I then told the administrator which file listed the lines to check. For what it's worth, I think the software developer should bear a lot of responsibility for helping to troubleshoot user problems. That means sanity checking, it means some sort of debugging flag in the *final* product (Uutry -x is my favorite example), it means some sort of message that the user can at least quote to field support (and preferably, messages that tell the user the *real* problem!), etc. It's also very useful to list and review all of the error messages, so the documentor include them in the manual, and ask, "What does this *really* mean?" That last question is an important one to ask any time you have an error message. IMHO, helping the user handle weird stuff is one of the things that differentiates "programming" from "software engineering". Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind.