Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!pyramid!csg From: csg@pyramid.pyramid.com (Carl S. Gutekunst) Newsgroups: comp.sys.pyramid Subject: Re: The Quality of Pyramid's Service Message-ID: <82908@pyramid.pyramid.com> Date: 2 Sep 89 02:05:44 GMT References: <82731@pyramid.pyramid.com> <3535@rtech.rtech.com> Reply-To: csg@pyramid.pyramid.com (Carl S. Gutekunst) Organization: Pyramid Technology Corp., Mountain View, CA Lines: 64 I said: >>RTOC takes thousands of calls every week. Greater than 90% of them are User >>Brain Damage: the person calling didn't understand what they were doing. In article <3535@rtech.rtech.com> markd@rtech.UUCP (Mark P. Diamond) writes: >This attitude really bothers me. Users are not stupid. Engineers, technical >writers and service people are stupid for thinking that they have built a >system which is easy to use. I didn't say anything about not *helping* the user. It's just that it if you assume that the user made a mistake, rather than assuming a system bug, you will be right almost all of the time. (UBD was a very poor choice of terms on my part, since it implies that the response was to RTFM. Not at all.) Where we (and everyone else!) can improve is in our skills at detecting when it really is a system bug, thereby reducing the frequency of customers complaining that their real bug reports are not being taken seriously. As I said, this is non- trivial. Many UNIX utilities have abysmal error recovery, meaning that user errors can produce behavior one would normally associate only with software bugs, e.g., core dumps. Incidentally, mistaking system bugs for user errors doesn't even happen all that often; but when it *does* happen, the customer feels put off, as if his competance was being questioned. I think that's why it's so commonly mentioned across the entire industry: even an isolated incident is very memorable. As far as preventing those sorts of calls in the first place: There is no question that UNIX documentation and user interface needs to be improved. A lot. Sun and AT&T each have more people working on UNIX documentation than we have in our entire R&D staff. Doing so will reduce the number of calls from users. There will never be a day, though, when users will stop calling with questions. IBM prints arguably the best documentation in the industry. I thought Sperry did an outstanding job in their day, too. But they still get a lot of questions from confused users. The reasons for this are multifold, but I'll site the two I see most often: - Users regularly attempt tasks larger than they are capable of handling, or for which the lack fundamental skills. This is inevitable. DP shops are usually understaffed, with everyone having to wear multiple hats. So they have to try new things with little or no warning or preperation. When they goof it up or get stuck, and don't know what to do next, they call the vendor. (If the project is late, they may try to *blame* the vendor.) - Users regularly fail to RTFM. There is no way around this simple fact. In the case of UNIX (and for that matter, IBM) this is often because they can't find what they are looking for, or because of previous unhappy experience trying to find something. That is the vendor's fault, and could properly be considered a "documentation bug." Unfortunately, this is the minority of cases. Even in UNIX. Fact is, a lot of people don't even try. UNIX also introduces another kicker: systems that are almost-but-not-quite the same. I've lost track of how many times something blew up because one system didn't didn't act "just like" a Sun, or a VAX, or a Pyramid, or a 3B20, etc. Of course, the user just proceeded in the way he was used to working. In both cases -- even the RTFM cases -- a good vendor holds the user's hand and gets them unstuck, and sometimes will refer them to an expert who can give them the background information that they need to understand what they are doing. That way, they can figure out similar future problems by themselves. The way to prevent calls about bugs, of course, is to never have any. :-)