Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site geowhiz.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!uwvax!geowhiz!karsh
From: karsh@geowhiz.UUCP (Bruce Karsh)
Newsgroups: net.unix-wizards
Subject: Re: Masscomp  (Actally manufacturers' support policies)
Message-ID: <236@geowhiz.UUCP>
Date: Sat, 7-Sep-85 06:39:41 EDT
Article-I.D.: geowhiz.236
Posted: Sat Sep  7 06:39:41 1985
Date-Received: Mon, 9-Sep-85 02:17:04 EDT
References: <1194@brl-tgr.ARPA> <2762@sun.uucp>
Reply-To: karsh@geowhiz.UUCP (Bruce Karsh)
Organization: UW Madison, Geology Dept.
Lines: 71


  In a previous article, I complained about some problems that we
were having with a computer system at our site.  From the responses I
received I have come to understand what a difficult problem the
computer manufacturers have.

  This is a topic that is of concern to unix-wizards, even though
it doesn't concern i-nodes, uucp, or group permissions.  Nearly
all wizards must take either in the manufacturers' position or the
customers' position, depending on the nature of the problem.

In article <2762@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>
>The objective of a small growth company is to make money.  If all your
>software engineers are tied up saying "RTFM" to customers, this makes it
>harder to make money.  The $80/hr fee is a price for a service, and serves
>to cut the demand so that it matches the supply of that service.  In this
>case, it tempts people to save themselves money by actually Reading The
>Manual before bitching to the vendor's technical support people.

     This is a real problem.  There are a lot of users out there who
     can not read the manuals.  Certainly, they should have to pay for
     consulting help.

     But what about cases where the customer has found a problem (i.e.
     a system bug, read the manual carefully in order to determine
     that the problem actually is a bug, and carefully characterizes
     the problem to the point where the problem can be reproduced
     at the factory.  It seems clear to me that it would be a big
     mistake for companies to treat these kinds of reports the same way
     as they treat "why does my Fortran compile give me all these
     error messages?" type reports.

     This is definitely a problem for the computer companies.  It takes
     time to determine whether a problem is a real bug, or an RTFM.
     And time is money; big money in the case of software engineers.
     Can a cursory inspection of a problem report reliably separate RTFM's
     from bugs?  How are the various computer companies handling the problem?

     Secondly, what should a manufacturer's responsibilities be in the
     case of software failures.  In the case of hardware failures,
     almost all companies have the same policy: fix it quickly.  In the
     case of IBM mainframes, "quickly" normally means within hours.
     In the case of minis, quickly usually means within a couple of
     days.  Of course, if you don't have a service contract, they will
     charge a lot for repairs.  But you can still get them done pretty
     rapidly.

     But broken software is fundamentally different from broken hardware.
     First, hardware problems are usually component failures and are
     repaired by replacing failed components with standardized interchangable
     parts.  Wouldn't it be nice if we could do this with software?  ( I.e.,
     "This loop is broken.  Let's see if we have another one in the supply
     room." )  Secondly, hardware failures are not normally design failures.
     Software failures are always design failures.  Thus they require a much
     deeper understanding of the whole system in order to repair them.

     On the other hand, from the point of view of the user, a software
     failure is as damaging as a hardware failure if they both prevent you
     from doing what you need to do.  Thus the user needs the same kind
     of response to both kinds of failure.

    So the question is, should manufacturers repair software failures
    with the same rapidity as they do hardware failures?
-- 

Bruce Karsh
U. Wisc. Dept. Geology and Geophysics
1215 W Dayton, Madison, WI 53706
(608) 262-1697
{ihnp4,seismo}!uwvax!geowhiz!karsh