Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!msi.umn.edu!src.honeywell.com!uwm.edu!zaphod.mps.ohio-state.edu!caen!rphroy!teemc!ka3ovk!raysnec!shwake
From: shwake@raysnec.UUCP (Ray Shwake)
Newsgroups: comp.std.c
Subject: Re: Shipping bogus code
Message-ID: <116@raysnec.UUCP>
Date: 25 Oct 90 20:26:40 GMT
References: <27098@mimsy.umd.edu> <1990Oct22.231028.24623@zoo.toronto.edu> <18632@rpp386.cactus.org> <1990Oct24.173121.20610@druid.uucp>
Organization: IRS/CI - Technical Solutions Branch
Lines: 24

darcy@druid.uucp (D'Arcy J.M. Cain) writes:

>The same with software.  If you run a
>system utility and it immediately dumps core then you can safely say that
>someone didn't do their job.  If it dumps core only when run at the stroke
>of midnight then you can say it has a bug but you can understand why it
>wasn't caught by the testing group.

	Agree completely. A somewhat different problem involves failure
to test components of a package already in wide use. The assumption is 
that, if the package has been around long enough in enough hands, it's 
*got* to be stable, right? Often true, but not always.

	Many years ago I was working on PWB Accounting on a System III
Zilog. After much frustration trying to resolve a problem involving the
monthly update procedure, I traced the culprit to a missing comment quote
in 'monacct'. Some time later, I was playing with a Plexus - nice box at
the time. Found the same bug. A year or two later got my hands on the
first IBM RT. Guess what... the bug was still there!

	Each vendor worked from common source; that vendor presumably
tested his enhancements and customization, but assumed everything else
*had* to be OK. Though the above sample bug and fix was reported to each
vendor, I wonder how many boxes still carry it.