Why bugs don't get fixed (was Re: Trusting operating systems: vendor

[j. eric townsend]

In article <8013 at brl-smoke.ARPA>, gwyn at brl-smoke.UUCP writes:
> In article <1133 at mcgill-vision.UUCP> mouse at mcgill-vision.UUCP (der Mouse) writes:

> >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]".

I don't find this too unrealistic, but it seems very, very optimistic
to expect a working solution.

> 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.

Heh.  When I worked for a small banking software firm, this was one
of our favorite replies.  Our customer support people, as they were,
coddled the customer till us techies could come up with an answer.
Luckily, we had written the the code in such a hurry, and so loosely,
that we could either convince the user that it was: really a feature;
unimportant, and wouldn't affect the rest of the program; that we could
ship a patched version that afternoon (this was true most of the time[1]);
or that it was EDS's fault :-).  (Apologies to EDS employees, but hey...)

[1]:  Our program specs changed on a daily basis.  Our product, its
user interface, and large parts of the program were subject to change
w/o any real notice to the *programmers*.  The president would get
a "brain fart" and tell us how we were supposed to do it now, and it
had to be ready by tomorrow, because he'd already sold two.  %90 of
the time, he hadn't sold any, and he'd change his mind next week... :-)

> 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

HAHAHAHAHAHAHA... I guess that makes only really increadibly huge
companies "responsible software organizations"..  I've never understood
how smaller companies could do the full QC required by common sense.
Maybe someone could write an AI system to beta-test software/make it
crash.  Our pres would tell us to do it the above way, with
"rethinking the solution as to benefit the product as a whole", and to
"fully test our fix before submitting the fixed product to QC".  Then
he'd tell us to have it done in 3 days.... :-)

Moral:  If you don't have a degree, go to work for a screwy little company
with only a small chance of success.  You'll get to bunches of different
neat things, write bunches of code (sometimes over and over again :-(,
and then hang around for the slow death of the company while making
a tidy sum to write the ultimate c-tree while they think you're
writing the code you did last week...
-- 
                                Know Future

J. Eric Townsend ->uunet!nuchat!flatline!erict smail:511Parker#2,Hstn,Tx,77007
             ..!bellcore!tness1!/