From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a60e2f124b42a104
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8)
Date: 1998/02/13
Message-ID: <dewar.887377152@merv>#1/1
X-Deja-AN: 324750462
References: <199802130604.WAA06276@mail.easystreet.com>
 <34E3F577.4BAB@easystreet.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 887377838 44 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-02-13T00:00:00+00:00
List-Id: <comp.lang.ada>


Al said

<<There used to be a CASE tool vendor out west that had a policy of
only calling a release a major release (i.e. version nnn.00) when
the known (to them) bug list was down to zero.  Perhaps that company
was one of the ancestors of the current Aonix?
>>

Although this *sounds* like a good policy, it is actually unsound.

Bugs vary greatly in their importance. Some bugs are really barely bugs
at all, but more like suggestions for something that would be a bit nicer
behavior in some situation. Some bugs are in situations so marginal that
the probability of them causing trouble is very low. Some bugs are ones
that are discovered by internal knowledge of the code, and are even more
marginal.

If you have a policy of not releasing until there are zero bugs, an
inevitable effect is to avoid even noticing bugs that are very marginal,
and instead ignoring them. If you avoid this policy, and don't mind having
a few marginal bugs around when you release, you will feel freer to keep
the minor bugs around on your bug list.

Remember that fixing a bug always has a risk. The risk is that it will
introduce an instability. This can be true even if the fix to the bug
is 100% correct, because what can happen sometimes is that fixing one
bug causes another latent bug to be more virulent.

So you only want to fix a bug if the risk of fixing it is less than the
risk of not fixing it, and this is a decision that has to be made in
each case. Sometimes of course, it depends where you are in the release
cycle. If you are close to a major release, then you are much more
circumspect about making changes.

Suppose Microsoft notices that in one rare situation, the color of one of
the Win98 icons is not quite what was intended, but the icon is still
perfectly readable. This is a bug, but we sure hope that Microsoft does
not try to fix this the day before they release the final WIn98 code :-)

Finally, in the flow of things, bugs get fixed, and bugs get reported.
There is nothing especially more reliable about one particular day when
the number of bugs *that you know about* happens to be at zero.

The above discussion is of course perfectly familiar to anyone involved
in software production management. The goals of the software release
are to provide a reliable product with minimal risks to the user. These
are rather different goals from producing bug free software, and they
are *very* different goals from producing software that *as far as you
know* has no bugs.

The reason it is worth noting these (rather obvious) observations is that
to an inexperienced user, the idea of releasing software with known errors
seems worrisome!