* Re: Bugs or Mistakes?
@ 1999-11-12 0:00 MaryAnn Atkinson
1999-11-13 0:00 ` Richard D Riehle
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: MaryAnn Atkinson @ 1999-11-12 0:00 UTC (permalink / raw)
To: comp.lang.ada
Richard D Riehle wrote:
> What we call a "bug" is actually a mistake. Someone tried to do
> something and made a mistake. The mistake results in a defect.
> The defect is a potential run-time fault. Managers need to take
> the responsibility for elminating the word "bug" from the
> vocabulary of their software personnel.
Why so harsh words? You are talking about a "bug" like its
a dirty word, or like we are somehow not allowed to make them...
Bugs are mistakes ONLY if they are not found and corrected!
MAA
P.S. Besides, you can't easily make a verb out of "mistake", you know?
What, am I going to be "demistaking" my code now?
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-12 0:00 Bugs or Mistakes? MaryAnn Atkinson @ 1999-11-13 0:00 ` Richard D Riehle 1999-11-15 0:00 ` Ted Dennison ` (2 more replies) 1999-11-13 0:00 ` Larry Kilgallen 1999-11-13 0:00 ` M. 2 siblings, 3 replies; 19+ messages in thread From: Richard D Riehle @ 1999-11-13 0:00 UTC (permalink / raw) In article <19991112202656.2368.rocketmail@web216.mail.yahoo.com>, MaryAnn Atkinson <maryann_30@yahoo.com> wrote: >Richard D Riehle wrote: > >> What we call a "bug" is actually a mistake. Someone tried to do >> something and made a mistake. > >Why so harsh words? You are talking about a "bug" like its >a dirty word, or like we are somehow not allowed to make them... > >Bugs are mistakes ONLY if they are not found and corrected! I knew at the time of my posting that this concept would arouse a certain amount of indignation. At least I hoped it would. In my experience, the word "bug" is often used as a euphemism to deemphasize personal responsibility for a set of mistakes. Many programmers do not take a "bug" as seriously as we might hope. A "bug" is something that originates outside your program. The original "bug" was, in the apocrypha of our industry, an actual moth wriggling into oblivion between the contacts of a hardware relay. Both the system and bug died. In our current use of the word, only the system dies. The bug remains intact, ready to kill again, until it is discovered and exterminated. Most of the phenomena we call "bugs" are the result of our own action, not the random accidents of innocent lepidoptera. Our actions are mistakes. Sometimes we make a mistake in our specification. Sometimes it is a mistake in our code. Now and then, the mistake originates in someone else's code that we naively trust in creating our own. I have long believed that software managers should begin to insist that programmers should be accountable for their mistakes. When I say, "I have a bug in my program," I am really saying, "I made a mistake." As long as programmers euphemize away their mistakes by calling them "bugs," we will not be accepting the kind of responsibility for our actions demanded of other engineering disciplines. It is, to me, quite telling that there are those who have sent me private correspondence on this matter expressing their indignation. "Bug" has such a long history of usage that we simply accept it as the way things are. We often hear someone say, "There is no such thing as 'bug free' software." I interpret the person saying that to mean, "No one knows how to build software that is free of mistakes." Robert Eachus made a very good point in a separate posting about the responsibility of a designer of bolts targeted to the construction of a bridge. Is a bolt that cannot handle the stress of its load a "bug?" No. We would consider it a mistake. It is an engineering mistake. In a computer program, a mistake leads to a defect and the defect to a possible execution fault. The fault might simply mangle some accounting data or it might kill some elderly patient depending on a CCU monitor. It is probably OK to call it a "bug" when the outcome is benign. More and more, our software is human-rated. If you are not familiar with the term, human-rated means that someone can die or be maimed if it fails. For that kind of software we need to start acknowledging the severity of our mistakes by calling them just that. >P.S. Besides, you can't easily make a verb out of "mistake", you know? > What, am I going to be "demistaking" my code now? Clever, but unpersuasive. How about doing what any other engineer would do about a mistake? If I make an error in the design of a mechanical device, I do not "debug" it, I correct it. Debugging a program is nothing more than correcting the mistakes. It is interesting that the use of the prefix, de-, in this context implies a removal of some pestilence from the code. The connotation is that, "Golly. I did what I was supposed to do, but some nefarious organism has begun to gnaw at it. I must find this organism and destroy it." When I have a mistake in my code, and I have a knack for producing lots of mistakes, I do what you and everyone else must do: correct those mistakes. Perhaps it sastisfies some primitive instinct to imagine that correcting mistakes is like eradicating evil spirits. If I treat the correction process as if it were an exorcism, I can have the satisfaction of conquest. Perhaps I can paste little pictures of spotted arthropods on my computer in imitation of fighter pilots who paint enemy flags on a fuselage. Sorry, MaryAnn. I am just having too much fun with this whole idea. Sometimes I simply go berserk about these things. I'd better quit now and wipe the white dribble from the corner of my mouth before it begins to foam uncontrollably. Richard Riehle ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Richard D Riehle @ 1999-11-15 0:00 ` Ted Dennison 1999-11-15 0:00 ` Robert I. Eachus 1999-11-17 0:00 ` Marin Condic 2 siblings, 0 replies; 19+ messages in thread From: Ted Dennison @ 1999-11-15 0:00 UTC (permalink / raw) In article <80i9la$i9e$1@nntp9.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > In article <19991112202656.2368.rocketmail@web216.mail.yahoo.com>, > MaryAnn Atkinson <maryann_30@yahoo.com> wrote: > > In my experience, the word "bug" is often used as a euphemism > to deemphasize personal responsibility for a set of mistakes. > Many programmers do not take a "bug" as seriously as we might hope. Considering that I tend to see engineers (myself included) take bugs *too* personally, I find this attitude a bit amusing. > As long as programmers euphemize away their mistakes by calling them > "bugs," we will not be accepting the kind of responsibility for our > actions demanded of other engineering disciplines. In many walks of life you see efforts to change the way people think about things by changing the word used to describe said thing. It *never* works. Even if you can manage to change the word everyone uses, the meaning of the old word will just migrate with it. A good example is the word "shellshocked", which has now undergone several name changes in a futile effort to run away from its own meaning. Everyone working in this industry has pretty much the same concept of what "bugs" are. Its the term we use for what happens when software isn't working properly. You aren't going to be able to change how engineers think about them by calling them "mistakes" any more than marketing folks can change how customers think about them by calling them "misfeatures". -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Richard D Riehle 1999-11-15 0:00 ` Ted Dennison @ 1999-11-15 0:00 ` Robert I. Eachus 1999-11-15 0:00 ` Richard D Riehle 1999-11-17 0:00 ` Marin Condic 2 siblings, 1 reply; 19+ messages in thread From: Robert I. Eachus @ 1999-11-15 0:00 UTC (permalink / raw) Richard D Riehle wrote: > Robert Eachus made a very good point in a separate posting about the > responsibility of a designer of bolts targeted to the construction of > a bridge. Is a bolt that cannot handle the stress of its load a "bug?" > No. We would consider it a mistake. It is an engineering mistake. I was talking about another issue, who is (legally) responsible if and when the bolts fail. But since you bring it up, it stands as a very good example. If you design a building, run it through a finite-element simulation before signing the drawings, and find that the bolts specified are inadequate, this is a bug in your design, and you fix it and repeat the simulation. If the simulation does meet spec, but someone supplies or uses sub-standard materials or doesn't build to spec, then they are liable. (The suspended walkway collapse in St. Louis and the DC-10 crash on takeoff at O'Hare fall into this category.) But if the bolts do meet spec, and the actual conditions don't match the simulation, then you have the case of the John Handcock building in the Back Bay. The wind sometimes blew UP the building, and sucked out windows. The solution was to replace the windows with stiffer windows at significant cost. Who was at fault? In this case no one. The engineers had not been negligent, they had even tested models in a wind tunnel. But the models had not been large enough--and complex enough--to catch the effects of such things as the fresh water in Back Bay vs. salt water in the harbor. The result was that the Handcock tower was uniquely placed to trigger the uninversion of atmospheric inversions, and create local updrafts that exceeded the building's specifications. The Galloping Gertie bridge failed due to a similar local trigger, but in that case there was negligence. The winds were there before the bridge was built. Now we can discuss when a bug is not a mistake. A bug that never gets to the field can be the result of a mistake, but often a bug detected early is just that, a bug. For example, in Ada it is much more productive to let the compiler worry about elaboration order, and only consider it as a problem if the compiler can't find a solution. If judicious use of elaboration pragmas can sort it out, was there a mistake? Not really. It is much more efficient to allow the compiler to select an order to the extent the order irrelevant as long as it is within the rules. If you leave off a necessary pragma Elaborate_Body, and as a result use an uninitialized variable, that is a mistake, even if you do catch it during unit test. What is my point in all this? A bug may have resulted from many mistakes or none. Going around assigning blame for bugs is conterproductive until you have found what is wrong and why. It can also be counterproductive to label as mistakes errors in draft documents, schedules, or software. The process of accountability should only begin when someone signs off on something--or alternatively, when it is accepted or fielded without competent techincal approval. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-15 0:00 ` Robert I. Eachus @ 1999-11-15 0:00 ` Richard D Riehle 1999-11-16 0:00 ` Robert I. Eachus 0 siblings, 1 reply; 19+ messages in thread From: Richard D Riehle @ 1999-11-15 0:00 UTC (permalink / raw) My apologies for boring some of you with this thread. My thanks to those of you have sent email agreeing with me. As Robert Dewar has noted, this discussion has the potential for becoming "silly." Some have taken it seriously. For the record, I realize that almost everyone takes programming errors seriously whether they are called bugs, mistakes, or cucumbers. In article <383086EC.372545D1@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > If you design a building, run it through a finite-element >simulation before signing the drawings, and find that the bolts >specified are inadequate, this is a bug in your design, and you fix it >and repeat the simulation. Reading your full text, I find we agree on a number of points. However, I would still classify the above example as an engineering error. It still needs to be corrected. There is no identifiable entity analogous to a "bug" lurking in the design. >If the simulation does meet spec, but >someone supplies or uses sub-standard materials or doesn't build to >spec, then they are liable. (The suspended walkway collapse in St. >Louis and the DC-10 crash on takeoff at O'Hare fall into this category.) In this case, I would say there is an error in the specification. > But if the bolts do meet spec, and the actual conditions don't >match the simulation, then you have the case of the John Handcock >building in the Back Bay. The wind sometimes blew UP the building, and >sucked out windows. The solution was to replace the windows with >stiffer windows at significant cost. Ignorance of the laws of physics is no excuse. :-) Seriously, this kind of thing is quite common. In physical engineering, we are often faced with incomplete understanding of the properties of common materials under new conditions. Is it a mistake to go ahead and put people's lives at risk even when we are working off our best guess? Who was at fault? Really a different question. This is why insurance companies sometimes use an "act of God" clause in their policies. HmmmMMMMmmmm. God is a bug? >In this case no >one. The engineers had not been negligent, they had even tested models >in a wind tunnel. But the models had not been large enough--and complex >enough--to catch the effects of such things as the fresh water in Back >Bay vs. salt water in the harbor. The result was that the Handcock >tower was uniquely placed to trigger the uninversion of atmospheric >inversions, and create local updrafts that exceeded the building's >specifications. The Galloping Gertie bridge failed due to a similar >local trigger, but in that case there was negligence. The winds were >there before the bridge was built. No engineer would ever claim that that the data sheets were always adequate. In some cases the engineer will make a mistake in using the data. Other times, it will be insufficient testing. Still other situations are governed by the trade off of economics versus the cost of a lawsuit. For example, A famous case involving the design of an automobile led the engineers to realize that, under some circumstances, the gas tank could explode and kill the occupants of the car. The problem was handed off to the actuarial folks who determined that it would cost more to reengineer the car than pay off the lawsuits, if any, that would develop from such accidents. Who made that mistake? Is that a bug or an mistake? Is it simply a _feature_ as some software humorists have suggested? > Now we can discuss when a bug is not a mistake. A bug that never >gets to the field can be the result of a mistake, but often a bug >detected early is just that, a bug. In the words of William Gates, "We respectfully disagree..." It is simply an error that goes through a succession of corrections. >For example, in Ada it is much more >productive to let the compiler worry about elaboration order, and only >consider it as a problem if the compiler can't find a solution. The compilers I use give me error messages. If the program fails to elaborate correctly, there is still a mistake in my design. >If >judicious use of elaboration pragmas can sort it out, was there a >mistake? Not really. It is much more efficient to allow the compiler >to select an order to the extent the order irrelevant as long as it is >within the rules. The mistake, here, would be failure to test the results for correct execution. Correct execution will probably not occur in an incorrectly compiled [read elaboration order is incorrect] program. >If you leave off a necessary pragma Elaborate_Body, >and as a result use an uninitialized variable, that is a mistake, even >if you do catch it during unit test. No argument with this. I fully agree. > What is my point in all this? A bug may have resulted from many >mistakes or none. Going around assigning blame for bugs is >conterproductive until you have found what is wrong and why. I fully agree. It is always counterproductive to engage in the blame game during development. OTOH, it is not counterproductive to simply acknowledge that, as someone else noted, there are defects in the program. The defects did not create themselves. They were put there by someone through ommission or commission. The defects may be a function of inexperience, sloppiness, designing in an entirely unknown domain, or ... There is still no creature spontaneously springing to life, worrying its way through the code. Sometimes the mistake is all the way back in the compiler. We once had a C compiler that had a strange behavior with certain uses of pointer arithmetic. A bug in the compiler? No. A serious mistake made by the developers of the compiler. It can >also be counterproductive to label as mistakes errors in draft >documents, schedules, or software. I think this is the very place they should be so identified. The earlier in the process we identify errors as errors, the greater the potential for eliminating them before they become part of the actual design. The process of accountability should >only begin when someone signs off on something--or alternatively, when >it is accepted or fielded without competent techincal approval. You and I have both sent a lot of documents through the approval process. In the early stages, the differences of opinion are niether mistakes or bugs. Often, they are simply differences in how we perceive the goals and suggested solutions. So in this general principle I agree with you. It does seem clear that we both agree that, once a software system is deployed, it is too late to euphemize the defects as bugs. At this level, given our increasingly litigious society, we'd better get used to the idea that some parasitic bottom dweller is going to rip open our brainchild, probing for the rotting tissue that proves we made some mistake. In this regard, your question, "Who was at fault," will not be satisfied by the answer, "Oh, it was just another bug." Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-15 0:00 ` Richard D Riehle @ 1999-11-16 0:00 ` Robert I. Eachus 1999-11-16 0:00 ` Richard D Riehle 0 siblings, 1 reply; 19+ messages in thread From: Robert I. Eachus @ 1999-11-16 0:00 UTC (permalink / raw) Richard D Riehle wrote: > >If the simulation does meet spec, but > >someone supplies or uses sub-standard materials or doesn't build to > >spec, then they are liable. (The suspended walkway collapse in St. > >Louis and the DC-10 crash on takeoff at O'Hare fall into this category.) > > In this case, I would say there is an error in the specification. Huh? Where was the error in the specification in either of these two cases? If the DC-10 had been maintained in accordance with specifications, the cracks that caused the crash would never have occurred. If the suspended walkway had been build in accordance with the engineering design, it probably would not have collapsed. In the software world, the first would have been a programming error, not a design error, and the second would have been an error introduced during maintenance. > Ignorance of the laws of physics is no excuse. :-) Seriously, this > kind of thing is quite common. In physical engineering, we are often > faced with incomplete understanding of the properties of common > materials under new conditions. Which is why the designer is often faced with choices between "tried and true" practices, and newer less expensive or better technologies which have not been well tested. > Is it a mistake to go ahead and > put people's lives at risk even when we are working off our best > guess? Yes, when you phrase it like that. But when there is an unknown risk, you have no other choice. Remember that an unknown risk is very different from an unquantifiable risk. Three elements, mercury, fluorine, and radium killed chemists before enough was known about their properties so that proper precautions could be designed. In each case there was an unknown risk, that once known could be treated as an unquantifiable risk with other new elements as they were discovered. (Fluorine is still the only element that can displace oxygen in compounds. Other metals besides mercury evaporate and are harmful when inhaled, and there are many radioactive compounds other than radium--but radium is the only one that gives off an invisible gas that is radioactive.) Unknown risks are, by their nature, unavoidable. > Really a different question. This is why insurance companies sometimes > use an "act of God" clause in their policies. > HmmmMMMMmmmm. God is a bug? No, God is a teacher, but some lessons are more emphatic than others. As those lessons are learned, the number of "act of God" cases decreases. Hurricanes, floods, earthquakes, and volcanic eruptions are no longer treated as acts of God in this country, but as part of nature that must be allowed for in designing buildings, dams, and highways. As a result, the loss of life and property when those events do happen is much less than in countries where they are still treated as acts of God. I hope we soon get to the point where software is subjected to the same standards, and most bugs are treated as avoidable. We can continue to disagree as to the number of bugs that are unavoidable, but we certainly agree that the number is very, very small. Reminds me of a study that we did, years ago on software for fault-tolerant systems. We basically concluded that if the software started with one bug per hundred lines, you couldn't afford the cost of getting it to a one per 10,000 standard. If you were above one bug per thousand lines, the cost of getting to one per 10,000 or one per million was the same. (But nothing could remove specification errors other than to redo the requirements analysis with a new team.) > No engineer would ever claim that that the data sheets were always > adequate. In some cases the engineer will make a mistake in using > the data. Other times, it will be insufficient testing. Which is why the testing is the engineer's responsibility. The cases I discussed involved cases where the material provided for testing did not match the material actually used. Especially when the only "true" test is a destructive one, you have to rely on sampling. > > Now we can discuss when a bug is not a mistake. A bug that never > >gets to the field can be the result of a mistake, but often a bug > >detected early is just that, a bug. > > In the words of William Gates, "We respectfully disagree..." It is > simply an error that goes through a succession of corrections. Hmmm. If I am not sure of the syntax, is it a bug to use the compiler as a reference? There are obscure areas, even in Ada ;-), where the compiler is the best available reference. Those cases I don't consider errors, rather that the compiler is being used as a tool. > >For example, in Ada it is much more > >productive to let the compiler worry about elaboration order, and only > >consider it as a problem if the compiler can't find a solution. > > The compilers I use give me error messages. If the program fails to > elaborate correctly, there is still a mistake in my design. I think you miss my point. If possible it is a good idea to put pragma Elaborate_Body on packages to protect future users from elaboration errors. I think most software engineers recommend doing that. But what about cases where it is not clear that the pragma is necessary, but may--stress on may--interact with other units to prevent the compiler from finding an elaboration order? In my judgement, the best approach is to compile with the pragma, and only if it prevents elaboration do the work to determine if it can be safely removed. > >If > >judicious use of elaboration pragmas can sort it out, was there a > >mistake? Not really. It is much more efficient to allow the compiler > >to select an order to the extent the order irrelevant as long as it is > >within the rules. > > The mistake, here, would be failure to test the results for correct > execution. Correct execution will probably not occur in an incorrectly > compiled [read elaboration order is incorrect] program. Now you are mixing the two cases. And maybe I wasn't clear. If you choose to err on the side of caution, and let the compiler tell you to do the extra work to show that the precaution is not necessary, and also to allow more opportunity for maintenance to introduce errors, that is not a mistake, but... > >If you leave off a necessary pragma Elaborate_Body, > >and as a result use an uninitialized variable, that is a mistake, even > >if you do catch it during unit test. > > No argument with this. I fully agree. ...an error in the other direction is always a mistake, even if it is caught. Basically, introducing "unnecessary" checking is always much better than omitting necessary checks. (I have never found it necessary to remove checks to meet real-time deadlines, in fact, there have been cases where I recommended that the government "give" the contractor some of the schedule reserve to so that the contractor would not run around supressing "unnecessary" checks.) > I fully agree. It is always counterproductive to engage in > the blame game during development. OTOH, it is not counterproductive > to simply acknowledge that, as someone else noted, there are defects > in the program. The defects did not create themselves. They were > put there by someone through ommission or commission. The defects > may be a function of inexperience, sloppiness, designing in an > entirely unknown domain, or ... There is still no creature > spontaneously springing to life, worrying its way through > the code. If they are defects, sure. But until they have been identified as such, they are just reported bugs. > Sometimes the mistake is all the way back in the compiler. We once > had a C compiler that had a strange behavior with certain uses of > pointer arithmetic. A bug in the compiler? No. A serious mistake > made by the developers of the compiler. Hmmm. When I was teaching programming courses, I used to instruct students that, if something went wrong, the last place to look was at the compiler. At work the next day, I would write, compile, and run programs and if I found a bug, the first place I looked was in the compiler. Of course, I was working as a compiler developer, and testing my changes... > It can > >also be counterproductive to label as mistakes errors in draft > >documents, schedules, or software. > > I think this is the very place they should be so identified. The > earlier in the process we identify errors as errors, the greater > the potential for eliminating them before they become part of the > actual design. I think we are in violent agreement here. They are errors or omissions and they should be fixed as soon as possible. But a TBD in a draft is not a mistake, it is just a mark indicating that there is something which must be fixed before this leaves draft status. (A TBD remaining in the documentation when it is shipped to the customer is a big mistake. ;-) > It does seem clear that we both agree that, once a software > system is deployed, it is too late to euphemize the defects > as bugs. At this level, given our increasingly litigious > society, we'd better get used to the idea that some parasitic > bottom dweller is going to rip open our brainchild, probing > for the rotting tissue that proves we made some mistake. In > this regard, your question, "Who was at fault," will not be > satisfied by the answer, "Oh, it was just another bug." Unless you work for Microsoft! The quality of the garbage that Microsoft sends out as beta software is often abominable. And not just beta releases. MITRE does a very good job of vetting supported software before approving it for general use. With Microsoft, this often requires critical patches before approval. And talk about using bugs as a euphemism! Microsoft has "hot fixes" and "Service Packs," not patches. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-16 0:00 ` Robert I. Eachus @ 1999-11-16 0:00 ` Richard D Riehle 0 siblings, 0 replies; 19+ messages in thread From: Richard D Riehle @ 1999-11-16 0:00 UTC (permalink / raw) Robert, I appreciate your comments, agree with many of your counter arguments, but have elided them in the interest of brevity. In article <3831DA52.964E4748@mitre.org>, "Robert I. Eachus" <eachus@mitre.org> wrote: > I think we are in violent agreement here. They are errors or >omissions and they should be fixed as soon as possible. But a TBD in a >draft is not a mistake, it is just a mark indicating that there is >something which must be fixed before this leaves draft status. (A TBD >remaining in the documentation when it is shipped to the customer is a >big mistake. ;-) We have no real difference of opinion here. A TBD is certainly just a note about something that actually needs to be determined. And a TBD deployed, is irresponsible. >> ... your question, "Who was at fault," will not be >> satisfied by the answer, "Oh, it was just another bug." > > Unless you work for Microsoft! The quality of the garbage that >Microsoft sends out as beta software is often abominable. And not just >beta releases. MITRE does a very good job of vetting supported >software before approving it for general use. With Microsoft, this >often requires critical patches before approval. And talk about using >bugs as a euphemism! Microsoft has "hot fixes" and "Service Packs," not >patches. No argument here. The junk sold by Microsoft is outrageous. Worse is their penchant for using economic muscle to destroy better competing products. But that is another story, isn't it. The Judge has ruled on this and the remedies are still pending his decisions. I think we stop bugging our colleagues any further bandwidth about bug versus mistake. Some people have corresponded with me in agreement. Others have decided that I am some kind of a nut. I suspect the latter group is more on the mark. Those who actually know me will realize they are. Thanks for a spirited discussion. Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Richard D Riehle 1999-11-15 0:00 ` Ted Dennison 1999-11-15 0:00 ` Robert I. Eachus @ 1999-11-17 0:00 ` Marin Condic 1999-11-19 0:00 ` Robert Dewar 2 siblings, 1 reply; 19+ messages in thread From: Marin Condic @ 1999-11-17 0:00 UTC (permalink / raw) Richard D Riehle wrote: > In my experience, the word "bug" is often used as a euphemism > to deemphasize personal responsibility for a set of mistakes. > Many programmers do not take a "bug" as seriously as we might hope. But even the word "mistake" implies a lack of personal responsibility. How many times have we heard a press secretary from some government agency or politician's office announce to the press "Mistakes Were Made" when the reality is "so-and-so committed a crime punishable by law". Perhaps "design defects" is a more accurate description of what we commonly call "bugs" MDC -- Marin David Condic, Word Scientist. If you hurry you can, for a short time only, still find me at: Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-17 0:00 ` Marin Condic @ 1999-11-19 0:00 ` Robert Dewar 1999-11-20 0:00 ` Michael Stark 0 siblings, 1 reply; 19+ messages in thread From: Robert Dewar @ 1999-11-19 0:00 UTC (permalink / raw) In article <3832E75B.2B6E7E1E@pwfl.com>, condicma@pwflcom wrote: > Perhaps "design defects" is a more accurate description of > what we commonly call "bugs" I don't like lumping all bugs into design flaws. To me a design flaw is quite a different beast from a typo introduced during implementation, and it is useful in preventing, finding, tracking, ande removing bugs to make the distinction. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-19 0:00 ` Robert Dewar @ 1999-11-20 0:00 ` Michael Stark 0 siblings, 0 replies; 19+ messages in thread From: Michael Stark @ 1999-11-20 0:00 UTC (permalink / raw) Robert Dewar wrote: > > In article <3832E75B.2B6E7E1E@pwfl.com>, > condicma@pwflcom wrote: > > Perhaps "design defects" is a more accurate description of > > what we commonly call "bugs" > > I don't like lumping all bugs into design flaws. To me a design > flaw is quite a different beast from a typo introduced during > implementation, and it is useful in preventing, finding, > tracking, ande removing bugs to make the distinction. > > Sent via Deja.com http://www.deja.com/ > Before you buy. Folks -- 1. Robert's objection can be taken care of by calling any problem a "defect" without the qualifier "design" 2. IEEE already has some useful definitions relating to defects -- I am paraphrasing, since I don't have the text in front of me failure -- the program doesn't run as expected and a user sees a problem fault -- the defect in the product that needs to be corrected error -- the conceptual problem that explains why a fault is in the system. Note -- a failure can occur when there is no fault in the system (e.g. user inputs values in English units rather than SI), and a fault can exist in code that isn't executed and thus doesn't cause a failure. Faults can be found either by running tests and noting failures, or inspecting one product against another (e.g. design vs. requirements, unit test plan vs. code,...) Thus ends my bried description of the IEEE view of defects ;) Mike -- Michael Stark Goddard Research & Study Fellow University of Maryland, College Park e-mail: mstark@cs.umd.edu phone (UM) 301-405-2721 phone (gsfc) 301-286-5048 "Half the world's population has never even made, or received, a telephone call" -- Kofi Annan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-12 0:00 Bugs or Mistakes? MaryAnn Atkinson 1999-11-13 0:00 ` Richard D Riehle @ 1999-11-13 0:00 ` Larry Kilgallen 1999-11-13 0:00 ` Vladimir Olensky 1999-11-13 0:00 ` M. 2 siblings, 1 reply; 19+ messages in thread From: Larry Kilgallen @ 1999-11-13 0:00 UTC (permalink / raw) In article <19991112202656.2368.rocketmail@web216.mail.yahoo.com>, MaryAnn Atkinson <maryann_30@yahoo.com> writes: > Richard D Riehle wrote: > >> What we call a "bug" is actually a mistake. Someone tried to do >> something and made a mistake. The mistake results in a defect. >> The defect is a potential run-time fault. Managers need to take >> the responsibility for elminating the word "bug" from the >> vocabulary of their software personnel. > > Why so harsh words? You are talking about a "bug" like its > a dirty word, or like we are somehow not allowed to make them... > > Bugs are mistakes ONLY if they are not found and corrected! What exists in the software is a defect. A mistake might be the action that introduced the defect, but since defects are often due to sins of omission rather than sins of commission, looking for the occasion on which the "mistake" was made might be difficult. Of course not all defects deserve to be fixed, especially since the fix often will destabilize the resulting software. My experience has been that organizations with the guts to use the term "defect" have a better chance at good quality control. Your mileage may vary. Larry Kilgallen ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Larry Kilgallen @ 1999-11-13 0:00 ` Vladimir Olensky 1999-11-13 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 19+ messages in thread From: Vladimir Olensky @ 1999-11-13 0:00 UTC (permalink / raw) Larry Kilgallen wrote in message <1999Nov12.201602.1@eisner>... > >My experience has been that organizations with the guts to use >the term "defect" have a better chance at good quality control. >Your mileage may vary. In industry where I have been working for many years before my current work there were no such word as "bug". There were such words as "design flaw", "error" and "defect" and that resulted in very strict and tight quality control methodology. Word "bug" implies something that lives independently from it's creator and thus creator is not so much responsible for what he did (or did not do to prevent this). Regards, Vladimir ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Vladimir Olensky @ 1999-11-13 0:00 ` Vladimir Olensky 1999-11-13 0:00 ` Nick Roberts 1999-11-13 0:00 ` Robert Dewar 0 siblings, 2 replies; 19+ messages in thread From: Vladimir Olensky @ 1999-11-13 0:00 UTC (permalink / raw) Vladimir Olensky wrote in message ... > >In industry where I have been working for many years >before my current work there were no such word >as "bug". There were such words as "design flaw", >"error" and "defect" and that resulted in very >strict and tight quality control methodology. This passage contains small "bug" in programming language sense but it called grammar error in normal language sense Instead of writing " had been working" I wrote "have been working". What is it - "bug" or an "error" ? This also illustrates the common source of such errors which is the code modification without proper checking how it affects other portions of code. When I started writing this there were no words "before my current work" and everything was OK. After inserting them in my "code" everything has changed. There exists another "bug" which was caused by removing one word out of several in succession but not changing relevant verb ("were no such word as ..."). It is also called grammar error in normal language sense. A lot of programmers like to name such things as "bugs". Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Vladimir Olensky @ 1999-11-13 0:00 ` Nick Roberts 1999-11-13 0:00 ` Richard D Riehle 1999-11-14 0:00 ` Robert Dewar 1999-11-13 0:00 ` Robert Dewar 1 sibling, 2 replies; 19+ messages in thread From: Nick Roberts @ 1999-11-13 0:00 UTC (permalink / raw) The story of the origin of the term 'bug' (the one that I heard, anyway), was back in the dark old days when a computer would fill an entire basement of a block, and have a cooling system like a wind tunnel. These cooling systems would inevitably develop areas of high humidity, and being also nice and warm, it was not unknown for such areas to be colonised by various insectival lifeforms. Occasionally, it is held, a bug would fall into the circuitry, causing sporadic anomalous misbehaviour. Naturally, this became the simplest way to explain any and all incorrect program behaviour to the (then utterly clueless) management. Nowadays, nobody is fooled. I have always liked the following definition from the 'Demon IT Book of Definitions': Debugger: the gentleman who sold you the software in the first place. :-) -- Nick Roberts ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Nick Roberts @ 1999-11-13 0:00 ` Richard D Riehle 1999-11-14 0:00 ` Robert Dewar 1999-11-14 0:00 ` Robert Dewar 1 sibling, 1 reply; 19+ messages in thread From: Richard D Riehle @ 1999-11-13 0:00 UTC (permalink / raw) In article <382DBE57.97B04F1E@callnetuk.com>, Nick Roberts <nickroberts@callnetuk.com> wrote: >Occasionally, it is held, a bug would fall into the circuitry, causing >sporadic anomalous misbehaviour. Naturally, this became the simplest way >to explain any and all incorrect program behaviour to the (then utterly >clueless) management. Sometimes the "bug" is the manager who keeps you from getting the work done necessary to correct a problem, someone who bugs you until you do something even more extreme. Hickam AFB, circa 1967: A forty-eight bit word Honeywell 800 was an important part of the computer center. There was problem with it, clearly hardware-related. One Colonel kept interrrrrrrupting the technician, asking questions about the problem. Honeywell had to send in a tech rep from the U.S. Mainland to help solve it. He had been warned about the inquistive Colonel. "Well, Colonel, this is a sophisticated Honeywell 800 with a 48 bit word. Somehow a forty-ninth bit is showing up. We need to eradicate that 49th bit and everything will be OK." Long after the problem was fixed, the Colonel could be heard showing off his computer expertise by telling people about the 49th bit. Richard Riehle ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Richard D Riehle @ 1999-11-14 0:00 ` Robert Dewar 0 siblings, 0 replies; 19+ messages in thread From: Robert Dewar @ 1999-11-14 0:00 UTC (permalink / raw) In article <80kklc$p4n$1@nntp6.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > Long after the problem was fixed, the Colonel could be heard > showing off his computer expertise by telling people about the > 49th bit. Well, straying further from the topic, which is a bit silly anyway :-) I read a review of a new computer game in a UK games magazine that gushed: XYZ is the first video game to really use the full 16-bits of power of the new ABC video game system. Previous games for this system have only used part of its power, perhaps 10 or 11 bits. :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Nick Roberts 1999-11-13 0:00 ` Richard D Riehle @ 1999-11-14 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 1999-11-14 0:00 UTC (permalink / raw) In article <382DBE57.97B04F1E@callnetuk.com>, Nick Roberts <nickroberts@callnetuk.com> wrote: > The story of the origin of the term 'bug' (the one that I > heard, anyway), was back in the dark old days <<rest of bogus piece of urban legend snipped>> See my quote from the OED, bug is an old term that preceded computer programming, and was simply adopted by early programmers. Yes, we have all heard the story you quoted. Treat it as a lesson not to believe everything you hear! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-13 0:00 ` Vladimir Olensky 1999-11-13 0:00 ` Nick Roberts @ 1999-11-13 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 1999-11-13 0:00 UTC (permalink / raw) Note that bug is a very old word in engineering usage, long preceding the appearence of computers. The first quote in the OED is from Thomas Edison: b. A defect or fault in a machine, plan, or the like, orig. U.S. 1889 Pall Mall Gaz. 11 Mar 1/1 "Mr. Edison, I was informed, had been up the two previous nights discovering 'a bug' in his phonograph--an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble." Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Bugs or Mistakes? 1999-11-12 0:00 Bugs or Mistakes? MaryAnn Atkinson 1999-11-13 0:00 ` Richard D Riehle 1999-11-13 0:00 ` Larry Kilgallen @ 1999-11-13 0:00 ` M. 2 siblings, 0 replies; 19+ messages in thread From: M. @ 1999-11-13 0:00 UTC (permalink / raw) MaryAnn Atkinson wrote in message <19991112202656.2368.rocketmail@web216.mail.yahoo.com>... >Richard D Riehle wrote: >> What we call a "bug" is actually a mistake. Someone tried to do >> something and made a mistake. The mistake results in a defect. >> The defect is a potential run-time fault. Managers need to take >> the responsibility for elminating the word "bug" from the >> vocabulary of their software personnel. > >Why so harsh words? You are talking about a "bug" like its >a dirty word, or like we are somehow not allowed to make them... They aren't harsh words; they're accurate words -- unlike "bug." There is a surprising attitude change that comes with eliminating "bug" from one's professional vocabulary. It does away with the illusion that the program is a personage working against the programmer. It eliminates the idea that a bad design can be debugged to a some level of acceptability -- which in turn discourages programmers from rushing to code. For management, it enables greater precision in classifying defects. You've got a "bug," you say? Is it a coding defect, design defect, or specification defect? How am I going to revise the schedule if I don't know? Have you ever, during a job interview, asked an employer, "How many mistakes am I allowed to make per week?" Of course not! Nobody's saying that mistakes aren't allowed, only that programmers should have serious quality standards. >Bugs are mistakes ONLY if they are not found and corrected! That's not a very useful observation. Given program X, how do you determine the number of defects that have not been found and corrected? >P.S. Besides, you can't easily make a verb out of "mistake", you know? > What, am I going to be "demistaking" my code now? Correcting. Fixing. Removing defects. M. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1999-11-20 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-12 0:00 Bugs or Mistakes? MaryAnn Atkinson 1999-11-13 0:00 ` Richard D Riehle 1999-11-15 0:00 ` Ted Dennison 1999-11-15 0:00 ` Robert I. Eachus 1999-11-15 0:00 ` Richard D Riehle 1999-11-16 0:00 ` Robert I. Eachus 1999-11-16 0:00 ` Richard D Riehle 1999-11-17 0:00 ` Marin Condic 1999-11-19 0:00 ` Robert Dewar 1999-11-20 0:00 ` Michael Stark 1999-11-13 0:00 ` Larry Kilgallen 1999-11-13 0:00 ` Vladimir Olensky 1999-11-13 0:00 ` Vladimir Olensky 1999-11-13 0:00 ` Nick Roberts 1999-11-13 0:00 ` Richard D Riehle 1999-11-14 0:00 ` Robert Dewar 1999-11-14 0:00 ` Robert Dewar 1999-11-13 0:00 ` Robert Dewar 1999-11-13 0:00 ` M.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox