Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!brl-adm!adm!rbj@icst-cmr.arpa
From: rbj@icst-cmr.arpa (Root Boy Jim)
Newsgroups: comp.unix.questions
Subject: Trusting operating systems: vendor or university?
Message-ID: <16105@brl-adm.ARPA>
Date: 8 Jun 88 19:14:37 GMT
Sender: news@brl-adm.ARPA
Lines: 62


   From: Doug Gwyn  <gwyn@brl-smoke.arpa>

   >And my notion of fixing a bug involves getting
   >a fix to the person with the problem within a week.  Not "in the next
   >major release - and oh yes, that will cost you $2500[1]".

   This is an entirely unrealistic notion.  Even when I set up a corporate
   software support organization with adequate staffing, all that we
   promised was a RESPONSE to an official trouble report within one week.

Well, that is true, but only because the world we know is an imperfect one.
Nevertheless, their is an `implied warranty of merchantibilty' on all
goods sold. One could conceivably take a vendor to court because the
system did not perform as stated in the documentation or specifications.
The fact that this is not done is further evidence that the courts do
not understand software, and that other solutions are livable.

   The response would not necessarily include a "fix" for the problem,
   although often we would promise fixes in the future and suggest interim
   workarounds.  Quite often the trouble reporter had not found an actual
   software error, but rather had misinterpreted the specs, and the
   response would include an explanation to help the reporter understand.

Fair enuf where it applys.

   Our reporting mechanism was designed to elicit sufficient information
   for use to be able to reproduce the problem, but often we couldn't, so
   investigating it was hopeless and we would have to so respond.  Other
   times the response was "We duplicated the problem but have not yet
   figured out what is responsible for it nor what to do about it.  We
   will continue to investigate and may do something about it in the
   future."  (Plus a suggested work-around, of course.)

Also fair enuf. However, often the problem is known and/or a specific
fix is suggested. Of course, this is only possible with source.

   Responsible software organizations do NOT install "quick fixes" in
   existing systems (except in extreme emergencies), but rather analyze
   the problem, design an integrated solution, assign competent staff
   to implement the solution, merge it into the product, thoroughly test
   not only the problem area but also the rest of the product operation,
   update documentation as required, run the result through QA to the
   distribution department.  Naturally this expensive process cannot be
   performed for every little bug, but is generally done on a regular
   basis for each product release cycle.  Most major vendors I have
   dealt with have procedures similar to what I just described.  Those
   few that have taken "quick fix" approaches I've generally found to
   cause more damage than they repair.

Again, in an ideal situation. But the bug *I* complain about is the most
important one, and I should get it fixed for free, because that's the
promise the vendor made (that it would work) when I bought it. If the
vendor wants to ship me a whole new system to fix my one bug, hey, that's
OK with me too, but I shouldn't have to pay for it.

	(Root Boy) Jim Cottrell	<rbj@icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	The opinions expressed are solely my own
	and do not reflect NBS policy or agreement
	My name is in /usr/dict/words. Is yours?