Trusting operating systems: vendor or university?

[Daniel R. Levy]

In article <8013 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
# 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.

Would you care to give some case histories showing how you found this to
be so?  (You can leave out the names to protect the guilty.)  This assertion
would seem to imply a corollary that a raw bug fix is more likely than not
to create another bug.  My own experience with quick fixes (with internal
CAD tools here at AT&T, developed and supported by Bell Labs) has been quite
good.  The tools are by no means bug-free, BUT I've rarely if ever seen a
quick fix introduce another bug.
-- 
|------------Dan Levy------------|  THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
|    AT&T  Data Systems Group    |  Weinberg's Principle:  An expert is a
|        Skokie, Illinois        |  person who avoids the small errors while
|-----Path:  att!ttbcad!levy-----|  sweeping on to the grand fallacy.