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,e4b2dce209393666 X-Google-Attributes: gid103376,public From: Richard D Riehle Subject: Re: Business Week (12/6/99 issue) article on Software Quality Date: 1999/12/09 Message-ID: <82opns$7k2$1@nntp4.atl.mindspring.net>#1/1 X-Deja-AN: 558640152 References: <82hk54$cbc$1@nntp6.atl.mindspring.net> <82kv5j$k6p$1@nnrp1.deja.com> <384eabe7.13628242@news.netidea.com> <82mlvh$mb0$1@nntp9.atl.mindspring.net> <82ochh$27p$1@nnrp1.deja.com> Organization: MindSpring Enterprises X-Server-Date: 9 Dec 1999 17:43:24 GMT Newsgroups: comp.lang.ada Date: 1999-12-09T17:43:24+00:00 List-Id: In article <82ochh$27p$1@nnrp1.deja.com>, Robert Dewar wrote: >You cannot change the language to be the way you want it to be. >Sure, like Humpty-Dumpty in Alice, you can make words mean >whatever you like, but if you want to be understood, you need >to use words in a standard manner. The word "bug" has a securely >established meaning (which incidentally is well described in >the OED). We are not about to change the meaning radically >because one person thinks it would be good to do so. How then, Robert, do we distinguish between a mistake and a "bug?" Is a bug simply some mystical entity that gobbles up tasty little chunks of code, an arthopodic alimentary canal with no sense of responsibility at either end? Is a bug something we know is there, but cannot yet identify? Is a mistake a bug that we have identified? What is so difficult about calling a bug an error, or at least a defect that originates in an error? When we use the word bug, we are suggesting that we have no idea what is wrong with our program. I often hear it used to trivialize the presence of the so-called bug. I agree that the term is in widespread use. That does not make it a correct choice. I also agree that it is colorful and poetic. That does not improve its descriptive properties -- does not make it a more accurate representation of what is really going on. If we are really interested in promoting software practice to an engineering discipline, we will be more careful -- more precise -- in our terminology. When there is a defect in a program, it should be so identified. When that defect originates in a mistake, it should be so acknowledged. Informally, "bug" continues to be an attractive shorthand for some problem we don't understand. From an engineering perspective, we have a responsiblity to identify the causes of the "bug" and give it a name that corresponds to the error that caused it. Once it has been so identified, it is no longer a "bug" it is an engineering defect. We recently had a police helicopter crash here in Silicon Valley. The headlines this morning identify the problem in terms of some defect, not as some kind of bug. Dennison takes me to task for being a "shrill and crackpot." I hope that is not true, but we shrills and crackpots rarely realize it when we are correctly identified as such. My point of view is simply that no other branch of engineering, except software practice, consistently uses the word "bug" to label its errors and defects. It will always be difficult to take software seriously as an engineering discipline as long as its practitioners insist on placing the blame for its mistakes on some mystical creature. It is a poetic appelation with little engineering value. >Personally I think Juliet had it right, and to paraphrase > >"a bug by any other name would stink as bad" Again with the poetry. :-) I love poetry, as you know, Robert. I have been trying, as I compose this, to think of a counter-quote from Shakespeare -- there must be one -- but it does not come to me at the moment. I'll probably think of it by the end of the day, and it will then be too late. :-) Richard Riehle