comp.lang.ada
 help / color / mirror / Atom feed
From: sampson@cod.NOSC.MIL (Charles H. Sampson)
Subject: Re: Yearly Fees for Support of Compiler
Date: 8 May 91 19:57:22 GMT	[thread overview]
Message-ID: <3050@cod.NOSC.MIL> (raw)
In-Reply-To: 2222@ac17.cs.nps.navy.mil

In article <2222@ac17.cs.nps.navy.mil> nash@ac17.cs.nps.navy.mil (david nash) writes:
>                                      ...  In my mind, reputable companies
>that market software make an implicit promise of correctness to would-be
>buyers.  The gentleman to whom Mr. Taft responded was suggesting that they
>provide bug fixes without payment, not enhanced features.

     Actually, computer software is one of the few places where no promises
of correctness are made, at least explicitly, as many people have noted.
("This software is not warrantied at all.  If it causes your house to burn
down, don't blame us.")

     I just looked up the original article and as I read it the primary
issue is not bug fixes, it is support; the poster wanted the compiler
writers to look into a suspected bug.  Now, as a group, the compiler
vendors have a mixed record on bug fixes, probably a little worse than
for personal computer software in general.  I don't know why this is so.
Maybe it's because of the complexity.  (An Ada compiler is a lot more
complex than even a desktop publishing program.)  The issue of support
is quite different from that of fixing bugs, however.

     For over 10 years I was in charge of a compiler that had unlimited
free user support.  (Paid for with your tax dollars.  It was for one of
those strange DoD languages.)  A tremendous amount of time was spent try-
ing to discern exactly what the user had done.  Most users, trying to be
helpful, partially analyzed the problem themselves and filtered out "un-
important" information.  They were almost always wrong about what the
problem was ("array references don't work") and what was unimportant
(after 30 minutes of probing, "Oh, is that important?  Yes, I did insert
a line like that upstream.").  Furthermore, often the problem turned out
to be the user's, not a compiler bug.  I hope this doesn't sound like I'm
flaming my erstwhile users.  They were trying to be helpful and this situ-
ation just goes with the territory.  It was only a minor irritation to me,
occasionally worth a laugh around the coffee pot, but if I had been working
for a company trying to make a profit solely on the sales of that compiler,
I would have been substantially less sanguine about it.

     What is the solution?  I don't know.  Any good company has to have
some way of getting feedback from its customers.  An approach that is
initally appealing is to charge for support when the problem turns out
to be the user's, but make it free if he is reporting an actual bug.  My
guess is that this approach could end in some ugly finger pointing from
time to time, and probably generate some customer ill-will, exactly what
the vendors don't want or need.

                              Charlie

  reply	other threads:[~1991-05-08 19:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1991-05-08 18:24 Yearly Fees for Support of Compiler david nash
1991-05-08 19:57 ` Charles H. Sampson [this message]
1991-05-09  6:02   ` rharwood
1991-05-09 14:25   ` Jerry Callen
1991-05-09 16:05 ` Drew Johnson
1991-05-14 22:59 ` Robert I. Eachus
  -- strict thread matches above, loose matches on Subject: below --
1991-05-17 17:50 mcsun!cernvax!chx400!sicsun!disuns2!elcgl.epfl.ch!madmats
     [not found] <172546@<1991May3>
1991-05-07 14:26 ` stt
1991-05-08 18:44   ` Kevin Simonson
1991-05-09  7:28   ` Jim Showalter
1991-05-09 20:07     ` Charles H. Sampson
1991-05-10  5:59       ` Jim Showalter
1991-05-12 22:00         ` Erik Naggum
1991-05-16 14:52     ` David T. Lindsley
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox