🚀 go-pugleaf

In article <1992Dec22.151201.22766@kakwa.ucs.ualberta.ca> DMARTIN@vm.ucs.UAlberta.CA writes:
>Maybe I'm misunderstanding what you mean by a "bug level", but I'm having
>difficulty with what you propose. WHAT IS an "acceptable bug level", defined
>so that I know when I have reached it? You can't simply ask that there be
>no more than x "minor bugs" present in the software - that gets you into
>a variation of the issue of proving software correct (How can I possibly KNOW
>that I am down to x "minor bugs" and 0 "major bugs"?).

As several others have posted, the reasonable goal is not "less than N
bugs" but "less than N *known* bugs".  We all realize that software that's
powerful enough to be useful is too complex to be perfect.  But if a vendor
knows about a serious bug when they ship the software then they're clearly
giving higher priority to deadlines than to quality.

The question arises: how do you prove that the vendor knew about the bug?
And even if the vendor admits to knowing about it, they might not agree
that it's a serious bug.  If it only affects .1% of users, is it serious?
Maybe not to the vendor, but if you're in the .1% it probably seems so.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar