* Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8) [not found] <199802130604.WAA06276@mail.easystreet.com> @ 1998-02-12 0:00 ` Al Christians 1998-02-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 4+ messages in thread From: Al Christians @ 1998-02-12 0:00 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8) 1998-02-12 0:00 ` INFO-ADA Digest - 12 Feb 1998 (#1998-8) Al Christians @ 1998-02-13 0:00 ` Robert Dewar 1998-02-13 0:00 ` Larry Kilgallen 1998-02-19 0:00 ` INFO-ADA Digest - 12 Feb 1998 (#1998-8) - Bugs Nick Roberts 0 siblings, 2 replies; 4+ messages in thread From: Robert Dewar @ 1998-02-13 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8) 1998-02-13 0:00 ` Robert Dewar @ 1998-02-13 0:00 ` Larry Kilgallen 1998-02-19 0:00 ` INFO-ADA Digest - 12 Feb 1998 (#1998-8) - Bugs Nick Roberts 1 sibling, 0 replies; 4+ messages in thread From: Larry Kilgallen @ 1998-02-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: INFO-ADA Digest - 12 Feb 1998 (#1998-8) - Bugs 1998-02-13 0:00 ` Robert Dewar 1998-02-13 0:00 ` Larry Kilgallen @ 1998-02-19 0:00 ` Nick Roberts 1 sibling, 0 replies; 4+ messages in thread From: Nick Roberts @ 1998-02-19 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1998-02-19 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <199802130604.WAA06276@mail.easystreet.com> 1998-02-12 0:00 ` INFO-ADA Digest - 12 Feb 1998 (#1998-8) Al Christians 1998-02-13 0:00 ` Robert Dewar 1998-02-13 0:00 ` Larry Kilgallen 1998-02-19 0:00 ` INFO-ADA Digest - 12 Feb 1998 (#1998-8) - Bugs Nick Roberts
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox