Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8)

Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8)

[Al Christians]

> From: Larry Kilgallen <kilgallen@EISNER.DECUS.ORG>
>
> In article <34E32C78.41C6@snv.jussieu.fr>, Dominique Bouthinon
> <Dominique.Bouthinon@snv.jussieu.fr> writes:
> > Are there known bugs in Object Ada (Aonix) ?
>
> Yes, there are known bugs in all software shipping from all vendors.
>

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?

Al

Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8)

[Larry Kilgallen]

In article <dewar.887377152@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> 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.

Regardless of whether the policy is good or bad, it is certainly
contrary to the industry norm, where the .0 versions are used for
the most new-feature laden (and thus the most buggy) releases. By
definition, the reason for the releases which do not have new features
is to fix bugs.

> 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 :-)

Well, that's not how we Macintosh fans feel :-).

Larry Kilgallen

Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8)

[Robert Dewar]

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!

Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8) - Bugs

[Nick Roberts]

I'm not disagreeing with anything that Robert says (in this post ;-), but I
would add that many software producers keep their bug lists secret, and
release software which has significant bugs in it without ever telling
their customers.

It seems to me that releasing a piece of software with any number of bugs
in it is perfectly decent, _provided_ that the paying customer is told
about the bugs in advance, and that all users are told about them with
receipt of the product.

It's the deception which is really immoral (on a practical level).  I could
tell a few stories!

== Nick Roberts ================================================
== Croydon, UK                       ===========================
==                                              ================
== Proprietor, ThoughtWing Software                   ==========
== Independent Software Development Consultant            ======
== Nick.Roberts@dial.pipex.com                              ====
== Voicemail & Fax +44 181-405 1124                          ===
==                                                            ==
==           I live not in myself, but I become               ==
===          Portion of that around me; and to me             ==
====         High mountains are a feeling, but the hum        ==
=======      Of human cities torture.
===========                             -- Byron [Childe Harold]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.887377152@merv>...
[about the practicalities of releases with minor 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!