* Business Week (12/6/99 issue) article on Software Quality @ 1999-12-01 0:00 Michael P. Card 1999-12-01 0:00 ` Preben Randhol ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Michael P. Card @ 1999-12-01 0:00 UTC (permalink / raw) ( I aplolgize if this ends up being posted twice, but I am not sure my first posting attempt succeeded- Mike) Fellow members of the Ada community: � I do not know if any of you have seen the 12/6 issue of Business Week, but it has a feature article on poor software quality. This article is specifically focused on the cost to business/drag on the economy caused by buggy software. There is a 1-page article on Watts Humphrey which compares him to Deming and briefly describes the SEI. � I think that it would be a very good idea for the members of this forum to write Business Week, or perhaps even get an interview with the authors of this story (what about it, Mr. Riehle? Mr. Taft?), to describe the benefits of Ada. I doubt that the folks at BW know anything about Ada or how it was designed to help this problem; I didn't see any mention of Ada when I scanned this article, but I haven't read it in depth yet. � If the costs of poor quality software are so bad that BW has noticed and devoted a feature article to it, perhaps the tide can yet turn in Ada's favor. � - Michael Card � -- Lockheed Martin Ocean, Radar and Sensor Systems Electronics Park, Building 6, Room 201 Syracuse, NY 13221 315-456-3022 Voice�� 315-456-0441 FAX michael.p.card@lmco.com -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==---------- http://www.newsfeeds.com The Largest Usenet Servers in the World! ------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-01 0:00 Business Week (12/6/99 issue) article on Software Quality Michael P. Card @ 1999-12-01 0:00 ` Preben Randhol 1999-12-01 0:00 ` Michael P. Card 1999-12-07 0:00 ` Richard D Riehle 1999-12-01 0:00 ` ld 1999-12-02 0:00 ` John Duncan 2 siblings, 2 replies; 44+ messages in thread From: Preben Randhol @ 1999-12-01 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 675 bytes --] "Michael P. Card" <houseofcards@surfree.com> writes: | ( I aplolgize if this ends up being posted twice, | but I am not sure my first posting attempt | succeeded- Mike) | | Fellow members of the Ada community: | � | I do not know if any of you have seen the 12/6 | issue of Business Week, but it has a | feature article on poor software quality. This Is it this article you are referring to: http://www.businessweek.com/1999/99_49/b3658015.htm ? -- Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/] "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-01 0:00 ` Preben Randhol @ 1999-12-01 0:00 ` Michael P. Card 1999-12-07 0:00 ` Richard D Riehle 1 sibling, 0 replies; 44+ messages in thread From: Michael P. Card @ 1999-12-01 0:00 UTC (permalink / raw) Preben- The article you cite is from the on-line version of Business Week International. The text seems to be mostly the same as the US print version, but it is missing a "sidebar" (or in this case "top bar") which shows a timeline of the costliest software failures from January 1998 through November 1999. There are some real whoppers in the list (billion dollar NASA satellites lost, commercial satellite losses due to software-induced rocket failures, system failures at Charles Schwab, etc.). The article on Watts Humphrey is also missing. - Mike -- > From: Preben Randhol <randhol@pvv.org> > Organization: ProgramVareVerkstedet > Newsgroups: comp.lang.ada > Date: 01 Dec 1999 14:06:00 +0100 > Subject: Re: Business Week (12/6/99 issue) article on Software Quality > > "Michael P. Card" <houseofcards@surfree.com> writes: > > | ( I aplolgize if this ends up being posted twice, > | but I am not sure my first posting attempt > | succeeded- Mike) > | > | Fellow members of the Ada community: > | � > | I do not know if any of you have seen the 12/6 > | issue of Business Week, but it has a > | feature article on poor software quality. This > > Is it this article you are referring to: > http://www.businessweek.com/1999/99_49/b3658015.htm > > ? > -- > Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/] > "Det eneste trygge stedet i verden er inne i en fortelling." > -- Athol Fugard -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==---------- http://www.newsfeeds.com The Largest Usenet Servers in the World! ------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-01 0:00 ` Preben Randhol 1999-12-01 0:00 ` Michael P. Card @ 1999-12-07 0:00 ` Richard D Riehle 1999-12-08 0:00 ` Robert Dewar 1999-12-08 0:00 ` Ted Dennison 1 sibling, 2 replies; 44+ messages in thread From: Richard D Riehle @ 1999-12-07 0:00 UTC (permalink / raw) >"Michael P. Card" <houseofcards@surfree.com> writes: >| I do not know if any of you have seen the 12/6 >| issue of Business Week, but it has a >| feature article on poor software quality. This I have sent the following letter to the editor at Business Week. -- ================================================================= Software development is the only engineering wannabee that euphemizes its mistakes with the cutsey monicker, "bug." The IEEE has suggested a three level designation starting with "mistake/error", that produces a software "defect" which causes an run-time error. We are still a long way from an engineering view of software in practice. Our methods are antiquated, our most commonly used programming languages are characterized by their brittleness, and our education of software developers is archaic. There is some hope on the horizon. An increasing number of universities are offering graduate programs in software engineering. Reliability-oriented programming languages such as Ada and Eiffel are becoming more frequently used for safety-critical software. Consumers, including corporate software users, are becoming more astute about the kinds of questions they ask reagarding the quality issue. Most commercial software developers are so devoted to the financial bottom line, they focus on forcing their customers to upgrade to marginally useful "neat" features rather than pay attention to quality. Many of the larger software publishers think "great" software consists of features reminiscent of the tail fins and excess chrome found on U.S. automobiles circa 1958-1975. Software development for Department of Defense weapon systems has been the exception. The bottom line for a missile is life or death. Engineering becomes more important than programming. A pilot engaging air-to-air missile countermeasures would not be pleased to see a "Blue Screen" message, "Sorry. System Error. Please Reboot." The Business Week article mentions the Boeing 777, a product programmed almost entirely in Ada. This project exemplifies the benefits of the engineering discipline originally applied in the development of military weapon systems. The value of Ada in creating DoD weapon systems is a seldom told story. If one reads the disclaminer on the back of the envelope in which commercial software is packaged, they will see that the software publisher is responsible only for the quality of the media on which the product was delivered. The product itself is not guaranteed, not warrantable, not necessarily going to work as advertised. What other manufacturer could get away with this? Richard Riehle, Suite 30, 2555 Park Boulevard, Palo Alto, CA 94306 (650) 328-1815 richard@adaworks.com ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-07 0:00 ` Richard D Riehle @ 1999-12-08 0:00 ` Robert Dewar 1999-12-08 0:00 ` Richard D Riehle 1999-12-08 0:00 ` Greg Martin 1999-12-08 0:00 ` Ted Dennison 1 sibling, 2 replies; 44+ messages in thread From: Robert Dewar @ 1999-12-08 0:00 UTC (permalink / raw) In article <82hk54$cbc$1@nntp6.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > Software development is the only engineering wannabee that > euphemizes its mistakes with the cutsey monicker, "bug." Seeing as the first recorded use of this word is by Thomas Edison, in connectin with work on some electronics, this seems a dubious claim. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Robert Dewar @ 1999-12-08 0:00 ` Richard D Riehle 1999-12-08 0:00 ` Greg Martin 1 sibling, 0 replies; 44+ messages in thread From: Richard D Riehle @ 1999-12-08 0:00 UTC (permalink / raw) In article <82kv5j$k6p$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: >In article <82hk54$cbc$1@nntp6.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: > >> Software development is the only engineering wannabee that >> euphemizes its mistakes with the cutsey monicker, "bug." > > >Seeing as the first recorded use of this word is by Thomas >Edison, in connectin with work on some electronics, this >seems a dubious claim. Although this may be historically accurate, contemporary engineering practice does not encourage the use of "bug." In fact, Edison, for all of his genius, was operating at a level of engineering discipline somewhat parallel to the early days of unstructured programming. Much of his work was equivalent of what Pressman calls, "exploratory programming." I stand by my claim that no responsible engineer, in any other discipline, would give the excuse that, "The bridge collapsed because there was a bug," or "The circuit fried because of a bug." Granted that some IC manufacturers have adopted this terminology to account for errors in their own designs, but the fact remains that these are errors, not bugs. They originate in 1) incomplete understanding of the physics, 2) failure to work out the logic correctly, 3) occasional negligence, 3) excessive haste, or any number of other factors. When an automobile gas tank explodes due to a collision with another car, is that a function of a bug? Of course not. An engineering discipline in its infancy may be able to assign mystical properties to the mistakes it makes and call them bugs. As that engineer becomes more mature, the engineers and engineering management become more responsible, more precise in their language. Sometimes we may not know what error created the defect. We would want to admit that and go on to find the error. Fortunately, this is exactly what good programmers do about bugs. Sadly, some major software publishers continue to release software in which they acknowledge "known bugs," a phrase that has the effect of minimizing the importance of the defects. If that software were released with a list of "known mistakes" one can imagine the litigation that might ensue. Richard Riehle ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Robert Dewar 1999-12-08 0:00 ` Richard D Riehle @ 1999-12-08 0:00 ` Greg Martin 1999-12-08 0:00 ` Keith Thompson 1999-12-09 0:00 ` Robert Dewar 1 sibling, 2 replies; 44+ messages in thread From: Greg Martin @ 1999-12-08 0:00 UTC (permalink / raw) On Wed, 08 Dec 1999 06:51:31 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote: >In article <82hk54$cbc$1@nntp6.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: > >> Software development is the only engineering wannabee that >> euphemizes its mistakes with the cutsey monicker, "bug." > > >Seeing as the first recorded use of this word is by Thomas >Edison, in connectin with work on some electronics, this >seems a dubious claim. > A person I worked for some 15 years ago had been a programmer since the days of relays for logic circuits. He claimed the word came from instances of insects preventing the closing of relays and hence the phrase "a bug in the program". Prehaps not accurate but amusing myth making none-the-less! Regards, Greg Martin. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Greg Martin @ 1999-12-08 0:00 ` Keith Thompson 1999-12-08 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Robert Dewar 1 sibling, 1 reply; 44+ messages in thread From: Keith Thompson @ 1999-12-08 0:00 UTC (permalink / raw) gregm@netidea.com (Greg Martin) writes: > A person I worked for some 15 years ago had been a programmer since > the days of relays for logic circuits. He claimed the word came from > instances of insects preventing the closing of relays and hence the > phrase "a bug in the program". Prehaps not accurate but amusing myth > making none-the-less! That incident actually occurred, on September 9, 1947. The "bug" was a moth in a relay of the Mark II, which was removed and pasted into the logbook by Grace Murray Hopper. There's a photo at <http://ei.cs.vt.edu/~history/Bug.GIF>. It's clear from the wording of the log entry, "First actual case of bug being found", that the term "bug" was already in use. For more information, see <http://www.tuxedo.org/~esr/jargon/html/entry/bug.html>. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> "Oh my gosh! You are SO ahead of your time!" -- anon. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Keith Thompson @ 1999-12-08 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 44+ messages in thread From: Richard D Riehle @ 1999-12-08 0:00 UTC (permalink / raw) In article <yecyab5f8lg.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: >That incident actually occurred, on September 9, 1947. The "bug" was >a moth in a relay of the Mark II, which was removed and pasted into >the logbook by Grace Murray Hopper. There's a photo at ><http://ei.cs.vt.edu/~history/Bug.GIF>. > >It's clear from the wording of the log entry, "First actual case of >bug being found", that the term "bug" was already in use. Excellent example of a "bug" as something that enters your product from outside. We find the same kind of "bug" in the form of cosmic radiation in satellites. This is a correct use of "bug." What programmers usually call a "bug" is a defect due to some mistake. That "bug" was created by us through ommission or commission. Richard Riehle ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Richard D Riehle @ 1999-12-09 0:00 ` Robert Dewar 1999-12-09 0:00 ` Richard D Riehle 1999-12-11 0:00 ` Jeffrey L Straszheim 0 siblings, 2 replies; 44+ messages in thread From: Robert Dewar @ 1999-12-09 0:00 UTC (permalink / raw) In article <82mlvh$mb0$1@nntp9.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > Excellent example of a "bug" as something that enters your > product from outside. We find the same kind of "bug" in the > form of cosmic radiation in satellites. This is a correct use > of "bug." What programmers usually call a "bug" is a defect > due to some mistake. That "bug" was created by us through > commission or commission. 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. Personally I think Juliet had it right, and to paraphrase "a bug by any other name would stink as bad" Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Robert Dewar @ 1999-12-09 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Roger Racine 1999-12-10 0:00 ` Ted Dennison 1999-12-11 0:00 ` Jeffrey L Straszheim 1 sibling, 2 replies; 44+ messages in thread From: Richard D Riehle @ 1999-12-09 0:00 UTC (permalink / raw) In article <82ochh$27p$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Richard D Riehle @ 1999-12-09 0:00 ` Roger Racine 1999-12-09 0:00 ` Richard D Riehle 1999-12-10 0:00 ` Vladimir Olensky 1999-12-10 0:00 ` Ted Dennison 1 sibling, 2 replies; 44+ messages in thread From: Roger Racine @ 1999-12-09 0:00 UTC (permalink / raw) On Thu, 09 Dec 1999 17:47:21 GMT, Richard D Riehle <laoXhai@ix.netcom.com> wrote: >In article <82ochh$27p$1@nnrp1.deja.com>, > Robert Dewar <robert_dewar@my-deja.com> 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? Why don't you look up the meaning in Robert's reference? There is no difference. A bug is a mistake that has not been diagnosed. The cause is not known, but the effect is seen. As if there were a bug in the system mucking things up. > >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. Exactly. We would have to say "I have an unknown problem in my program" instead of "I have a bug in my program." >I often hear it used to trivialize the presence of the so-called bug. > "Bug Report", "Problem Report", they mean the same thing. I agree that no one should trivialize problems where the cause is unknown. That happens too much no matter what term is used. For one example, the first Space Shuttle flight was delayed a couple days due to a bug (at the time the cause was unknown). It had been seen in simulations, but so seldom that it had not been resolved. The Shuttle flew with the error (it had been diagnosed by then, and was known to be an initialization timing problem with a probability of about 2%). Do not let trivialization happen, no matter what word is used. >Once it has been so identified, it is no longer a "bug" it is an >engineering defect. Agreed. And what is wrong with designating it that way? > >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. > Electrical Engineers also use the term. My guess is that software folks picked it up from them. Roger Racine ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Roger Racine @ 1999-12-09 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Ray Blaak ` (3 more replies) 1999-12-10 0:00 ` Vladimir Olensky 1 sibling, 4 replies; 44+ messages in thread From: Richard D Riehle @ 1999-12-09 0:00 UTC (permalink / raw) In article <384ffd52.888393602@newsnew.draper.com>, rracine@myremarq.com (Roger Racine) wrote: >Why don't you look up the meaning in Robert's reference? There is no >difference. A bug is a mistake that has not been diagnosed. The >cause is not known, but the effect is seen. As if there were a bug in >the system mucking things up. Ah, but we see the term being used, instead, for mistakes that are diagnosed, simply not yet corrected, as in "known bugs." Further, you have just acknowledged that a bug is just another word for a mistake. Thank you. >Exactly. We would have to say "I have an unknown problem in my >program" instead of "I have a bug in my program." And the problem with that is? >"Bug Report", "Problem Report", they mean the same thing. I agree >that no one should trivialize problems where the cause is unknown. >That happens too much no matter what term is used. For one example, >the first Space Shuttle flight was delayed a couple days due to a bug >(at the time the cause was unknown). It had been seen in simulations, >but so seldom that it had not been resolved. The Shuttle flew with >the error (it had been diagnosed by then, and was known to be an >initialization timing problem with a probability of about 2%). So we use "bug" to characterize some error that is not yet diagnosed. We use "error" once we understand the cause. If that were a consistent usage, no problem. It isn't. The "bug" report is too often a list of problems "we have not yet gotten around to fixing." This is certainly true of a little software company in the Northwest corner of the United States that some of us know and love. >>Once it has been so identified, it is no longer a "bug" it is an >>engineering defect. > >Agreed. And what is wrong with designating it that way? Nothing as long as it is accompanied by the admission of the error that caused it. >Electrical Engineers also use the term. My guess is that software >folks picked it up from them. I'm not sure about who used it first. It is all too often used in very sloppy ways. Robert cites its use by Edison, but Edison was an inventor, not an engineer. His work was similar to that of very creative programmers of our own time who, clever as they may be, are not thinking of software as an engineering process. In my own programs, the "bugs" are mistakes I have made. You may call it a bug. I still call it an error. I correct my errors. You exterminate bugs. The fact that I have not yet discovered my error does not make it less of an error. I prefer my own terminology. Sorry for being a "shrill and crackpot" over this. The real disappointment for me is that no one appreciated my reply to the Business Week article. Also, I suspect that those non-software people who read it, if it is published, will understand the point I am making without being defensive about the terminology. Only the software practitioners are likely to object. Interesting... Richard Riehle ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Richard D Riehle @ 1999-12-09 0:00 ` Ray Blaak 1999-12-11 0:00 ` Geoff Bull 1999-12-10 0:00 ` Vladimir Olensky ` (2 subsequent siblings) 3 siblings, 1 reply; 44+ messages in thread From: Ray Blaak @ 1999-12-09 0:00 UTC (permalink / raw) Richard D Riehle <laoXhai@ix.netcom.com> writes: > In my own programs, the "bugs" are mistakes I have made. You > may call it a bug. I still call it an error. [...] > > The real disappointment for me is that no one appreciated my reply to > the Business Week article. Also, I suspect that those non-software > people who read it, if it is published, will understand the point I am > making without being defensive about the terminology. Only the software > practitioners are likely to object. Interesting... Well, this software practitioner is not objecting. To me bugs are errors and are almost synonyms, the difference being that a bug is a particular kind of error, namely a programming error. So, I like to call them bugs, since I am a geek, but think of them as mistakes, since I like to take them seriously. It is a good thing to be reminded that bugs are our fault, not something that happens to us and our programs. Thanks. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Ray Blaak @ 1999-12-11 0:00 ` Geoff Bull 0 siblings, 0 replies; 44+ messages in thread From: Geoff Bull @ 1999-12-11 0:00 UTC (permalink / raw) Ray Blaak wrote: > > a bug is a particular kind of error, namely a programming error. > But, hardware also has bugs. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Ray Blaak @ 1999-12-10 0:00 ` Vladimir Olensky 1999-12-10 0:00 ` Roger Racine 1999-12-11 0:00 ` Geoff Bull 3 siblings, 0 replies; 44+ messages in thread From: Vladimir Olensky @ 1999-12-10 0:00 UTC (permalink / raw) Richard D Riehle wrote in message <82p3vo$k8v$1@nntp3.atl.mindspring.net>... >The real disappointment for me is that no one appreciated my reply to >the Business Week article. No, I do not think so. Those who appreciated just did not reply criticizing your style ;-) >Also, I suspect that those non-software >people who read it, if it is published, will understand the point I am >making without being defensive about the terminology. Only the software >practitioners are likely to object. Interesting... But understandable. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Ray Blaak 1999-12-10 0:00 ` Vladimir Olensky @ 1999-12-10 0:00 ` Roger Racine 1999-12-11 0:00 ` Geoff Bull 3 siblings, 0 replies; 44+ messages in thread From: Roger Racine @ 1999-12-10 0:00 UTC (permalink / raw) On Thu, 09 Dec 1999 20:42:14 GMT, Richard D Riehle <laoXhai@ix.netcom.com> wrote: >In article <384ffd52.888393602@newsnew.draper.com>, > rracine@myremarq.com (Roger Racine) wrote: > >>Why don't you look up the meaning in Robert's reference? There is no >>difference. A bug is a mistake that has not been diagnosed. The >>cause is not known, but the effect is seen. As if there were a bug in >>the system mucking things up. > >Ah, but we see the term being used, instead, for mistakes that are >diagnosed, simply not yet corrected, as in "known bugs." Further, >you have just acknowledged that a bug is just another word for >a mistake. Thank you. > The IEEE Standard Dictionary of Electrical and Electronics Terms has this definition: ----------------------- bug (2) (software). See: fault. fault (7) (software). (2) A manifestation of an error in software. Syn: bug. ---------------------- I do not think anyone is arguing against the idea that a bug is a fault is caused by a mistake and that is an error. Synonyms exist in the English language. We just do not want to lose one of those words for no useful purpose. "Manifestations of errors" will be given relative priorities, no matter what you call them. Ones that occur seldom and have little or no effect will be fairly low priority, and will not cause a program schedule to slip. Ones that occur often and have little effect might have to be thought about, since it could affect training ("what is that little flash on the screen in the upper left corner every so often?"). Some well-known software company, on the other hand, would not think twice about this level. Ones that are serious must be fixed (these that software company might think about :-) ). So think about the term "bug" being used for any strange effect that is seen in a program. Yes, the underlying error might be known but not fixed. And yes, people might be using the term interchangeably with error. The English language changes, but not generally based on requests from individuals. :-) Roger Racine ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Richard D Riehle ` (2 preceding siblings ...) 1999-12-10 0:00 ` Roger Racine @ 1999-12-11 0:00 ` Geoff Bull 3 siblings, 0 replies; 44+ messages in thread From: Geoff Bull @ 1999-12-11 0:00 UTC (permalink / raw) Richard D Riehle wrote: > > In article <384ffd52.888393602@newsnew.draper.com>, > rracine@myremarq.com (Roger Racine) wrote: > > >Why don't you look up the meaning in Robert's reference? There is no > >difference. A bug is a mistake that has not been diagnosed. The > >cause is not known, but the effect is seen. As if there were a bug in > >the system mucking things up. > > Ah, but we see the term being used, instead, for mistakes that are > diagnosed, simply not yet corrected, as in "known bugs." Further, > you have just acknowledged that a bug is just another word for > a mistake. Thank you. > By this meaning, a "debugger" must be an application that removes mistakes from your program. If only! :-) Cheers Geoff ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Roger Racine 1999-12-09 0:00 ` Richard D Riehle @ 1999-12-10 0:00 ` Vladimir Olensky 1999-12-09 0:00 ` Jerry Maple 1 sibling, 1 reply; 44+ messages in thread From: Vladimir Olensky @ 1999-12-10 0:00 UTC (permalink / raw) Roger Racine wrote in message <384ffd52.888393602@newsnew.draper.com>... >On Thu, 09 Dec 1999 17:47:21 GMT, Richard D Riehle ><laoXhai@ix.netcom.com> wrote: >> <...> 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. >Electrical Engineers also use the term. Being electrical (telecommunications) engineer for many years I've never heard the term "bug" applied to anything in electrical engineering. What I've heard so far was "fault" or "defect" as most commonly used words in industry. One may encounter " faulty circuit" or "defective circuit" but not "buggy circuit" :-) Or at Draper laboratory this is different ? :-) I doubt this. May be long long time ago when relays were widely used in electric equipment that could be the case especially in tropics but now it sounds amusing. But I should admit that I've seen once such accident in one remote place not a long time ago . Wall clock with electrical mechanism which was not placed in the protective box was spoiled by cockroaches. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-10 0:00 ` Vladimir Olensky @ 1999-12-09 0:00 ` Jerry Maple 1999-12-10 0:00 ` Vladimir Olensky 0 siblings, 1 reply; 44+ messages in thread From: Jerry Maple @ 1999-12-09 0:00 UTC (permalink / raw) On Fri, 10 Dec 1999 00:40:19 +0300, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote: <snip> >But I should admit that I've seen once such accident in one >remote place not a long time ago . Wall clock with >electrical mechanism which was not placed in the protective >box was spoiled by cockroaches. > >Regards, >Vladimir Olensky > > > > Many years ago I worked for Raytheon's Missile Systems Division in Massachusetts. We tested Hawk missile system shelters on a hilltop in Pelham, NH, where the radars could get a good look at the traffic flying into Logan airport. One of the "debugging" problems we had there was that mice and rats would get into the shelters and chew the insulation off the shelter wiring. They seemed to prefer the red insulation to the black. Red usually carried a supply voltage, while black was usually a ground. Made for a lot of fun finding the power supply short-circuits. Jerry Maple ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Jerry Maple @ 1999-12-10 0:00 ` Vladimir Olensky 0 siblings, 0 replies; 44+ messages in thread From: Vladimir Olensky @ 1999-12-10 0:00 UTC (permalink / raw) Jerry Maple wrote in message <385036b8.8552818@nntp.cig.mot.com>... >On Fri, 10 Dec 1999 00:40:19 +0300, "Vladimir Olensky" ><vladimir_olensky@yahoo.com> wrote: > ><snip> > >>But I should admit that I've seen once such accident in one >>remote place not a long time ago . Wall clock with >>electrical mechanism which was not placed in the protective >>box was spoiled by cockroaches. >> > >Many years ago I worked for Raytheon's Missile Systems Division >in Massachusetts. We tested Hawk missile system shelters on >a hilltop in Pelham, NH, where the radars could get a good look >at the traffic flying into Logan airport. One of the "debugging" >problems we had there was that mice and rats would get into the >shelters and chew the insulation off the shelter wiring. They seemed >to prefer the red insulation to the black. Red usually carried a >supply voltage, while black was usually a ground. Made for a >lot of fun finding the power supply short-circuits. That's true. As "bugs" are major software problem rats are common problem for ground and building cabling systems if they are not protected properly against that small animals. Regards, Vladimir Olensky ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Roger Racine @ 1999-12-10 0:00 ` Ted Dennison 1999-12-10 0:00 ` Richard D Riehle 1999-12-14 0:00 ` P.S> Norby 1 sibling, 2 replies; 44+ messages in thread From: Ted Dennison @ 1999-12-10 0:00 UTC (permalink / raw) In article <82opns$7k2$1@nntp4.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > I often hear it used to trivialize the presence of the so-called bug. If so, its a pretty weak attempt. At this point everyone knows what "bug" means. If you think the term excuses anything, you don't hang out in the newsgroups populated mostly by non-programmer software users. The best word to describe their reception of even minorly buggy software is "brutal". > 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 I did *not* call you that. I simply said that those are the two types of people who gravitate to the "we must change the word, and the meaing will somehow change too" arguments. I definitely don't deem you a crackpot, and you have about two more threads of this to go before you achieve full shrill-hood. (A state which I'm sure I have achieved on certian issues). > >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 Just make something up. It couldn't be much looser of a parahprase than Robert's. :-) How about: Alas, poor bug! I knew him, Horatio: a fellow of infinite jest, of most excellent fancy: he hath borne me on his back a thousand times; and now, how abhorred in my imagination it is! my gorge rims at it. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-10 0:00 ` Ted Dennison @ 1999-12-10 0:00 ` Richard D Riehle 1999-12-14 0:00 ` P.S> Norby 1 sibling, 0 replies; 44+ messages in thread From: Richard D Riehle @ 1999-12-10 0:00 UTC (permalink / raw) In article <82r7ao$293$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: >In article <82opns$7k2$1@nntp4.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: >> 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 > >I did *not* call you that. I simply said that those are the two types of >people who gravitate to the "we must change the word, and the meaing >will somehow change too" arguments. I definitely don't deem you a >crackpot, and you have about two more threads of this to go before you >achieve full shrill-hood. (A state which I'm sure I have achieved on >certian issues). Those of us who are entertained by this thread have now expressed our viewpoints. Those who are annoyed by it are becoming more annoyed. It is probably time to terminate it. I originally intended only to share the fact that I had responded to the Business Week article with something postive about Ada. It turned into a Donneybrook that I did not expect, but should have anticpated. Now let's see if any thing positive can come of it within the glossy pages of BW. No more on bugs versus mistakes, OK? Richard Riehle ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-10 0:00 ` Ted Dennison 1999-12-10 0:00 ` Richard D Riehle @ 1999-12-14 0:00 ` P.S> Norby 1 sibling, 0 replies; 44+ messages in thread From: P.S> Norby @ 1999-12-14 0:00 UTC (permalink / raw) Ted Dennison wrote: > > In article <82opns$7k2$1@nntp4.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: > > >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 > > Just make something up. It couldn't be much looser of a parahprase than > Robert's. :-) > > How about: > > Alas, poor bug! I knew him, Horatio: a fellow > of infinite jest, of most excellent fancy: he hath > borne me on his back a thousand times; and now, how > abhorred in my imagination it is! my gorge rims at > it. > "Out! Damned bug!" \\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\ \\\ ( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :) ( :) /// /// /// /// /// /// /// /// /// P.S. Norby "Software engineers are, in many ways, similar to normal people" -- Scott Adams "No excuses. No embarrassment. No apologies... Ada -- the most trusted and powerful programming language on earth, or in space." -- S. Tucker Taft ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Robert Dewar 1999-12-09 0:00 ` Richard D Riehle @ 1999-12-11 0:00 ` Jeffrey L Straszheim 1 sibling, 0 replies; 44+ messages in thread From: Jeffrey L Straszheim @ 1999-12-11 0:00 UTC (permalink / raw) 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. It is likely that none of us will succeed in changing the way folks talk about things; however, I shall still insist on calling the defects in my programs exactly that: "defects". I shall also call those in other software the same. I wish the consumer would insist on a similar strategy, and refuse to accept the watered-down term "bug" from the market drones who pawn bad software on us. They're defects; and the consumer shouldn't accept any other description. -- Jeffrey Straszheim -- Systems Engineer, Programmer -- http://www.shadow.net/~stimuli -- stimuli AT shadow DOT net ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Greg Martin 1999-12-08 0:00 ` Keith Thompson @ 1999-12-09 0:00 ` Robert Dewar 1 sibling, 0 replies; 44+ messages in thread From: Robert Dewar @ 1999-12-09 0:00 UTC (permalink / raw) In article <384eabe7.13628242@news.netidea.com>, gregm@netidea.com (Greg Martin) wrote: > A person I worked for some 15 years ago had been a programmer since > the days of relays for logic circuits. He claimed the word came from > instances of insects preventing the closing of relays and hence the > phrase "a bug in the program". Prehaps not accurate but amusing myth > making none-the-less! Well the proper origin of this story is Grace Hopper's well known description of an instance of exactly this problem. The mistake is that this is NOT the origin of the use of the word bug with respect to computer programs. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-07 0:00 ` Richard D Riehle 1999-12-08 0:00 ` Robert Dewar @ 1999-12-08 0:00 ` Ted Dennison 1999-12-08 0:00 ` Richard D Riehle 1999-12-08 0:00 ` jim_snead 1 sibling, 2 replies; 44+ messages in thread From: Ted Dennison @ 1999-12-08 0:00 UTC (permalink / raw) In article <82hk54$cbc$1@nntp6.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > I have sent the following letter to the editor at Business Week. > > -- ================================================================= > > Software development is the only engineering wannabee that euphemizes > its mistakes with the cutsey monicker, "bug." The IEEE has suggested > a three level designation starting with "mistake/error", that produces > a software As a reader, you loose me right here. This kind of lingusitc revisionism has throughout history been the exclusive domain of shrills and crackpots. There is ample proof that changing the word used to describe something has absolutely no impact on the meaning people give the concept. To make matters worse, the "improved" term is invariably longer and more mushy-mouthed. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Ted Dennison @ 1999-12-08 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Georg Bauhaus 1999-12-09 0:00 ` Ted Dennison 1999-12-08 0:00 ` jim_snead 1 sibling, 2 replies; 44+ messages in thread From: Richard D Riehle @ 1999-12-08 0:00 UTC (permalink / raw) In article <82lv4i$aso$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: >As a reader, you loose me right here. This kind of lingusitc revisionism >has throughout history been the exclusive domain of shrills and >crackpots. Don't hold back, Ted. As one of those "shrills and crackpots," I would want you to really say what you mean. Linguistic revisionism, indeed. >There is ample proof that changing the word used to describe >something has absolutely no impact on the meaning people give the >concept. The choice of a word can be quite important to how someone perceives a product or idea. Revolutions have been initiated through the clever selection of the right words. Advertising is about symbols. Words are symbols. The "movers and shakers," in the poem by Arthur O'Shaugnessy, are the "poets and music makers," people who often specialize in words. In the case of the word "bug" versus "mistake" I believe the correct choice of word does ultimately make a difference. Perhaps I am wrong. A lot of people think so. On the other hand, I am finding that a lot of people agree with me. >To make matters worse, the "improved" term is invariably longer >and more mushy-mouthed. Please craft your own response to the Business Week article if you find mine so odius. It will do no harm for the magazine to receive multiple submissions. The editors may then select from among those that seem most appropriate. Richard Riehle ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Richard D Riehle @ 1999-12-09 0:00 ` Georg Bauhaus 1999-12-10 0:00 ` Preben Randhol 1999-12-09 0:00 ` Ted Dennison 1 sibling, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 1999-12-09 0:00 UTC (permalink / raw) Richard D Riehle (laoXhai@ix.netcom.com) wrote: : The choice of a word can be quite important to how someone perceives : a product or idea. A question to the native English speakers: I read here in my English/German dictionary (1987) that "bug" in Britain quite definitely denotes an insect you would not want to meet on your mattress, whereas in North America it more generally denotes a rich set of small animals, mostly insects, and also ("Am. sl.") "Defekt". There are also references to "big bug" and "jitterbug". In Germany, the English word "bug" is in common use (in talking about programs), it is almost never translated, and if so, the German words for "beetle", "moth", or, well, "bug" are used, not all of which might evoke the same assiciations in every situation. At work, you can be sure to hear the english word "bug", I'd say. And you can be quite sure that programmers yho hear about (English:) bugs in their programs will twitch and shudder, BECAUSE they know these are mistakes. And German users of programs will show an expression of, at least, distaste if they see the program they try to use is malfunctioning, if functioning at all. ;-) Can you say what people in the English speaking countries feel or associate when they here "bug" in talking about programs? Georg Bauhaus ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Georg Bauhaus @ 1999-12-10 0:00 ` Preben Randhol 0 siblings, 0 replies; 44+ messages in thread From: Preben Randhol @ 1999-12-10 0:00 UTC (permalink / raw) sb463ba@d250-hrz.uni-duisburg.de (Georg Bauhaus) writes: | In Germany, the English word "bug" is in common use (in | talking about programs), it is almost never translated, and unfortunately "Bug" is much used in Norway too, but a lot of people actually use mistake (feil in Norwegian). -- Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/] "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Georg Bauhaus @ 1999-12-09 0:00 ` Ted Dennison 1999-12-09 0:00 ` Richard D Riehle 1 sibling, 1 reply; 44+ messages in thread From: Ted Dennison @ 1999-12-09 0:00 UTC (permalink / raw) In article <82mle2$3v3$1@nntp8.atl.mindspring.net>, Richard D Riehle <laoXhai@ix.netcom.com> wrote: > Please craft your own response to the Business Week article if you I'm not entirely sure it merited one. I agree that they missed a rather rich problem source in the obstinate use of error-prone languages. But at least they didn't *blame* Ada for problems. That's a good start. :-) > find mine so odius. It will do no harm for the magazine to receive > multiple submissions. The editors may then select from among those > that seem most appropriate. Being a cynic, I suspect that editors often select the letters that are the *least* sensible-sounding, or have bizzare or easily refutable points. Given that viewpoint, more letters would be a *bad* thing, as some are bound to be worse. :-) -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` Ted Dennison @ 1999-12-09 0:00 ` Richard D Riehle 0 siblings, 0 replies; 44+ messages in thread From: Richard D Riehle @ 1999-12-09 0:00 UTC (permalink / raw) In article <82p4de$ima$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: >In article <82mle2$3v3$1@nntp8.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: > >> Please craft your own response to the Business Week article if you > >I'm not entirely sure it merited one. I agree that they missed a rather >rich problem source in the obstinate use of error-prone languages. But >at least they didn't *blame* Ada for problems. That's a good start. :-) In fact, Ted, I did not intend to write a response. Then I was contacted by some people in the Ada community who suggested I write one. You are certainly correct that not blaming Ada was a good start. Once I decided to honor the request to write a response, I thought carefully about my audience. I realized that most of the readers are not software practitioners, but also that most of them have the opportunity to influence software decisions and raise good questions. In that spirit, I crafted each sentence quite carefully, made each one intentionally provocative, and inserted the mention of Ada as almost a "by the way." Perhaps I could have done this better had I taken more time. Perhaps it would be more acceptable to the software practitioners on this forum if I had first submitted it for approval. It is as it is. I cannot apologize for any part of it since no part of it, except the typo "disclaminer" was an accident. The entire piece, or some part of it may have been a mistake (not a bug), but that is another issue. >Being a cynic, I suspect that editors often select the letters that are >the *least* sensible-sounding, or have bizzare or easily refutable >points. Given that viewpoint, more letters would be a *bad* thing, as >some are bound to be worse. :-) A cynic? Bow wow! I never would have guessed that. :-) Seriously, Ted, your objections to my viewpoint are always welcome. I really do understand that my assertions are sometimes a bit over the top, but extremism in the defence of extremism is no vice. As to what editors select, I find they select letters based on some little phrase they find entertaining rather than what they find sensible. I tried to make the response entertaining, but who knows if they will find it so. Thanks for a lively conversation, Best regards from cla's resident shrill and crackpot, :-) Richard Riehle P.S. Some of my colleagues in Silicon Valley consider me a shrill and crackpot for espousing Ada. Sigh..... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` Ted Dennison 1999-12-08 0:00 ` Richard D Riehle @ 1999-12-08 0:00 ` jim_snead 1999-12-09 0:00 ` Ted Dennison 1999-12-09 0:00 ` John English 1 sibling, 2 replies; 44+ messages in thread From: jim_snead @ 1999-12-08 0:00 UTC (permalink / raw) In article <82lv4i$aso$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > In article <82hk54$cbc$1@nntp6.atl.mindspring.net>, > Richard D Riehle <laoXhai@ix.netcom.com> wrote: > > a three level designation starting with "mistake/error", that produces > > a software > As a reader, you loose me right here. This kind of lingusitc revisionism -------------------^^^^^ You can look it up, internet and email have revised the English language such that the term "loose" no longer means "not tight" but means the same as "lose" as in "lost". Another common net term is the completely fabricated single word "alot" meaning "a lot" or "many". These terms are not typos but learned net behavior. The studies make for some interesting reading. > has throughout history been the exclusive domain of shrills and > crackpots. There is ample proof that changing the word used to > describe > something has absolutely no impact on the meaning people give the > concept. To make matters worse, the "improved" term is invariably > longer > and more mushy-mouthed. * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free! ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` jim_snead @ 1999-12-09 0:00 ` Ted Dennison 1999-12-09 0:00 ` John English 1 sibling, 0 replies; 44+ messages in thread From: Ted Dennison @ 1999-12-09 0:00 UTC (permalink / raw) In article <004aa0e3.b7f5c816@usw-ex0102-011.remarq.com>, jim_snead <basswoodNObaSPAM@my-deja.com.invalid> wrote: > In article <82lv4i$aso$1@nnrp1.deja.com>, Ted Dennison > <dennison@telepath.com> wrote: > > In article <82hk54$cbc$1@nntp6.atl.mindspring.net>, > > Richard D Riehle <laoXhai@ix.netcom.com> wrote: > > > a three level designation starting with "mistake/error", that > produces > > > a software > > As a reader, you loose me right here. This kind of lingusitc > revisionism > > -------------------^^^^^ > > You can look it up, internet and email have revised the English > language such that the term "loose" no longer means "not tight" > but means the same as "lose" as in "lost". Another > common net term is the completely fabricated single word "alot" > meaning "a lot" or "many". > These terms are not typos but learned net behavior. The studies > make for some interesting reading. Yes, but those are instances of practicaly the opposite phenonomon: The set of concepts we as a society use in communicating our ideas are constantly changing. When a new concept evolves, we have to express it somehow. So we either make up words, or shoehorn it into already existing ones. That's completely different than claiming that you can somehow manage to change the underlying concept that society has agreed on simply by changing the set of characters used to represent it. There have been lots of attempts to do this, but not one success. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-08 0:00 ` jim_snead 1999-12-09 0:00 ` Ted Dennison @ 1999-12-09 0:00 ` John English 1999-12-09 0:00 ` Preben Randhol 1 sibling, 1 reply; 44+ messages in thread From: John English @ 1999-12-09 0:00 UTC (permalink / raw) jim_snead wrote: > You can look it up, internet and email have revised the English > language such that the term "loose" no longer means "not tight" > but means the same as "lose" as in "lost". Another > common net term is the completely fabricated single word "alot" > meaning "a lot" or "many". > These terms are not typos but learned net behavior. The studies > make for some interesting reading. Another interesting one I've seen several times is "wala", as in "you do this, and wala, it works"... presumably someone ignorant of French who heard someone else say "voila" started this one... ----------------------------------------------------------------- John English | mailto:je@brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk ----------------------------------------------------------------- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-09 0:00 ` John English @ 1999-12-09 0:00 ` Preben Randhol 0 siblings, 0 replies; 44+ messages in thread From: Preben Randhol @ 1999-12-09 0:00 UTC (permalink / raw) John English <je@bton.ac.uk> writes: | Another interesting one I've seen several times is "wala", as in | "you do this, and wala, it works"... presumably someone ignorant | of French who heard someone else say "voila" started this one... Not only the English language is affected. In Norwegian we don't split words as much as the English language does. Example: Radio frequency = radiofrekvens. But now more and more words are split (by people, the language is not changing) into two words. This is probably due to much exposure to the English language on the net and through other media. Sometimes you see such hopeless splits like (in an English equivalent) "forefathers" into "fore fathers" :-) -- Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/] "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-01 0:00 Business Week (12/6/99 issue) article on Software Quality Michael P. Card 1999-12-01 0:00 ` Preben Randhol @ 1999-12-01 0:00 ` ld 1999-12-01 0:00 ` Michael P. Card 1999-12-02 0:00 ` Preben Randhol 1999-12-02 0:00 ` John Duncan 2 siblings, 2 replies; 44+ messages in thread From: ld @ 1999-12-01 0:00 UTC (permalink / raw) In article <B46A7702.169C%houseofcards@surfree.com>, "Michael says... > >If the costs of poor quality software are so bad >that BW has noticed and devoted a >feature article to it, perhaps the tide can yet >turn in Ada's favor. > >- Michael Card So, let other software companies write bad software. You use Ada to write good software, make more money. Why do you want to tell the competition about something good you found? ld ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-01 0:00 ` ld @ 1999-12-01 0:00 ` Michael P. Card 1999-12-02 0:00 ` Preben Randhol 1 sibling, 0 replies; 44+ messages in thread From: Michael P. Card @ 1999-12-01 0:00 UTC (permalink / raw) ld- My appeal was intended to boost Ada's mindshare in the commercial world, which IMO benefits all software consumers. Many of us work for software producers during the day but we all buy products for ourselves too. I for one would welcome browsers, e-mail tools, operating systems etc. developed entirely in Ada (or Eiffel) by companies which follow sound software engineering principles. For this reason, I would like *everybody* to know about Ada and what it has to offer. - Mike -- > From: ld@- > Organization: - > Newsgroups: comp.lang.ada > Date: 1 Dec 1999 14:33:09 -0800 > Subject: Re: Business Week (12/6/99 issue) article on Software Quality > > In article <B46A7702.169C%houseofcards@surfree.com>, "Michael says... > >> >> If the costs of poor quality software are so bad >> that BW has noticed and devoted a >> feature article to it, perhaps the tide can yet >> turn in Ada's favor. >> >> - Michael Card > > So, let other software companies write bad software. You use Ada > to write good software, make more money. Why do you want > to tell the competition about something good you found? > > ld > > -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==---------- http://www.newsfeeds.com The Largest Usenet Servers in the World! ------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==----- ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-01 0:00 ` ld 1999-12-01 0:00 ` Michael P. Card @ 1999-12-02 0:00 ` Preben Randhol 1 sibling, 0 replies; 44+ messages in thread From: Preben Randhol @ 1999-12-02 0:00 UTC (permalink / raw) ld@- writes: | So, let other software companies write bad software. You use Ada | to write good software, make more money. Why do you want | to tell the competition about something good you found? Because if I go on a ferry or a plane or in other ways put myself in the mercy of technology, I would feel much better if I knew that I wouldn't be injured by buggy code. If I entered a plane and the captain said were flying the state-of-the-art with C coded software, I'd get out pretty quick :-) -- Preben Randhol -- [randhol@pvv.org] -- [http://www.pvv.org/~randhol/] "Det eneste trygge stedet i verden er inne i en fortelling." -- Athol Fugard ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-01 0:00 Business Week (12/6/99 issue) article on Software Quality Michael P. Card 1999-12-01 0:00 ` Preben Randhol 1999-12-01 0:00 ` ld @ 1999-12-02 0:00 ` John Duncan 1999-12-12 0:00 ` Ronald Caudill 2 siblings, 1 reply; 44+ messages in thread From: John Duncan @ 1999-12-02 0:00 UTC (permalink / raw) I was surprised at the BS in the article about how "rapid innovation" is responsible for defects. This is a line we've been hearing from makers of banal, overdone software for decades. Microsoft constantly tries to make us agree that their software is so innovative that we simply needed it out the door so fast that they couldn't spend the time to design it. In reality, there are many older Microsoft products I would prefer to use than the new versions, but they are now unsupported. Strangely, these products had the "simplicity" that Microsoft says they're struggling to achieve by amalgamating and bloating all of their code. Word 4.0 for the Mac is one of my favorite examples. But it is not until the lawsuit that these vendors seem to care about software quality. Quality software is truly not that hard to produce, but like any other product, you have to build the quality into it, and not expect to repair it as you go. We have plenty of programming languages now that make software quality easier to produce, such as Ada and ML, and we have plenty of methodologies, such as Cleanroom and Extreme Programming, that fit different cultures and product requirements to help assure quality. But instead of outrage, home users have been tortured so much that they are complacent, and they accept the fact that they have no voice. Large businesses will lose their voice as well, if we allow UCITA to be adopted by the states. Write a letter to your Governor and State Legislatures. Tell them that you are a software developer but, as a human being, you do not want to protect software houses in this manner. Do this before the option is taken away from you. -John ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-02 0:00 ` John Duncan @ 1999-12-12 0:00 ` Ronald Caudill 1999-12-13 0:00 ` David C. Hoos, Sr. 0 siblings, 1 reply; 44+ messages in thread From: Ronald Caudill @ 1999-12-12 0:00 UTC (permalink / raw) We have plenty of programming > languages now > that make software quality easier to produce, such as Ada and ML, > and we > have plenty of methodologies, such as Cleanroom and Extreme > Programming, > that fit different cultures and product requirements to help > assure quality. Hi John, I saw a vague reference to Cleanroom a couple of years ago in a programming book, but have been unable to find any information about it. Would you explain briefly what Cleanroom and Extreme Programming are and where I can get more information on them. Thank You. Ronald * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * The fastest and easiest way to search and participate in Usenet - Free! ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-12 0:00 ` Ronald Caudill @ 1999-12-13 0:00 ` David C. Hoos, Sr. 1999-12-13 0:00 ` John Duncan 1999-12-13 0:00 ` Ehud Lamm 0 siblings, 2 replies; 44+ messages in thread From: David C. Hoos, Sr. @ 1999-12-13 0:00 UTC (permalink / raw) Ronald Caudill <mrcaudillNOmrSPAM@yahoo.com.invalid> wrote in message news:1e9b4e00.977952a1@usw-ex0107-041.remarq.com... > > We have plenty of programming > > languages now > > that make software quality easier to produce, such as Ada and ML, > > and we > > have plenty of methodologies, such as Cleanroom and Extreme > > Programming, > > that fit different cultures and product requirements to help > > assure quality. > > > Hi John, > I saw a vague reference to Cleanroom a couple of years ago in a > programming book, but have been unable to find any information about it. > Would you explain briefly what Cleanroom and Extreme Programming are > and where I can get more information on them. Thank You. Ronald > A search on www.google.com with the single word Cleanroom yielded 9410 Hits of which the first was: http://www.clearlake.ibm.com/MFG/solutions/cleanrm.html That site appears to be at least a good starting point for learning about Cleanroom Software Engioneering. A similar search with the two words extreme programming yielded 50,600 hite, of which the first was: http://www.extremeprogramming.org/ Again, that site appears to be at least a good starting point for learning about Extreme Programming. > > > * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network * > The fastest and easiest way to search and participate in Usenet - Free! > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-13 0:00 ` David C. Hoos, Sr. @ 1999-12-13 0:00 ` John Duncan 1999-12-13 0:00 ` Ehud Lamm 1 sibling, 0 replies; 44+ messages in thread From: John Duncan @ 1999-12-13 0:00 UTC (permalink / raw) [snip links] Thanks for fetching those links for me. There's also a homepage for Cleanroom Software Engineering, but it might be down at the moment. It seemed like a side project of a consultant. Further, I have this link: http://www.amazon.com/exec/obidos/ASIN/0201385953/o/qid=945090562/sr=8-1/104 -0800228-5527666 Stavely, Allan M. "Toward Zero-Defect Programming". Addison Wesley, 1998 I found this book to be good, but like all process books, it does not directly help you with your application domain. You have to apply the principles to your work. Extreme Programming is a Smalltalk-spawn process framework. My guess is that if everyone switches to XP, more people will use Smalltalk. http://www.amazon.com/exec/obidos/ASIN/0201616416/qid%3D945090741/104-080022 8-5527666 Beck, Kent. "Extreme Programming Explained: Embrace Change". Addison Wesley, 1999. I've been hearing a lot of good feedback from the XP folks, but, you know, it has a sexy name. I know that SEI has been monitoring the XP stuff because Mark Paulk mentioned it at a SPIN meeting a few months ago. Beware of anything that will tell you learning a new way is easy. The XP guys say it is, but there is a lot of cultural change that has to take place before it will be truly understood by your organization. One problem with improvement is that the founding member of a new methodology is always respected well enough to get his own way. I am pretty sure that Dr. Mills never had any trouble getting the precise resources he needed to bring his vision to reality. I also think that the C3 project, the flagship of XP, is a very unique case. (Not a unique application, but a unique environment.) To institute change, you will need to envision the company as a whole after the change, and bring that state about. You will need to be able to assure people that, by following a new path, the company will be better and happier. You will need to show that your company is sick. If you can't do it yourself, shill the next highly paid consultant to pitch the plan for you. My advice to anyone who wants to see SPI occur in his organization is: 1. If you go around and tell people that they are doing it wrong, you will make enemies. Imagine if you wrote a nifty routine, and someone told you it was wrong because it had the wrong comment style. This is the way process improvement sounds when people use it in a condescending manner. Many times I have heard people say that they are _the_ above-average (star) programmer in their organizations. They say this on newsgroups, and people have to say either, "present co. excluded" or "I'm sure you can still improve." You may think you've figured it out, but so has everyone else. Look toward the "meek", the ones who don't think they've figured it out. They are the easily impressionable ones. Start discussion groups. Never act like you are right and "they" are all wrong. 2. If people think bosses are the trouble, they are already overencumbered by the system. They need to think that the bosses show symptoms of the systemic disease just as much as the workers do. Do you really think that it is upper management that is causing the problem? Look at yourself, and the people on your left and right. You all have much influence on the system, but you are probably not looking at your problems systemically. Get people into system thinking. 3. If you are not a shining example of the benefits of a little process control, people will not trust you. Perhaps you'd get a few things done, but if you are not actively improving, people will think it is all a joke. Work honestly at your own self-improvement. 4. If you show that you have stabilized the process, and then improved it to a much more productive and stable process, the data will speak for themselves. If you don't have a stable base to work from, what is the meaning of a good streak? Every now and again a project in a Level-1 org comes in well under budget and nearly defect-free. Is this a testament to the process? No, the history will show that eventually a number of projects will be killed for being late and costly, or full of defects. Try to figure out how to make everything predictable first, then work on increased returns. I think that the above four points will be useful. We'll notice that neither Cleanroom nor XP allows you to do it by yourself. In cleanroom, you need a bunch of people, but you can borrow them from project to project. In XP, you need at least two people, but to get the benefit the entire project needs to support the paradigm. I hope you all may have found this useful. -John ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: Business Week (12/6/99 issue) article on Software Quality 1999-12-13 0:00 ` David C. Hoos, Sr. 1999-12-13 0:00 ` John Duncan @ 1999-12-13 0:00 ` Ehud Lamm 1 sibling, 0 replies; 44+ messages in thread From: Ehud Lamm @ 1999-12-13 0:00 UTC (permalink / raw) You may find the links I have in my Misc. SE Links page useful. Looking under the heading "New Paradaigms in SE" (not a great name, I know...) you will find: http://c2.com/cgi-bin/wiki?ExtremeProgramming http://www.armaties.com/extreme.htm about Extreme Programming. A deja search on comp.object.moderated will produce many results too. Ehud Lamm mslamm@mscc.huji.ac.il http://purl.oclc.org/NET/ehudlamm <== My home on the web Check it out and subscribe to the E-List- for interesting essays and more! ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~1999-12-14 0:00 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-12-01 0:00 Business Week (12/6/99 issue) article on Software Quality Michael P. Card 1999-12-01 0:00 ` Preben Randhol 1999-12-01 0:00 ` Michael P. Card 1999-12-07 0:00 ` Richard D Riehle 1999-12-08 0:00 ` Robert Dewar 1999-12-08 0:00 ` Richard D Riehle 1999-12-08 0:00 ` Greg Martin 1999-12-08 0:00 ` Keith Thompson 1999-12-08 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Robert Dewar 1999-12-09 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Roger Racine 1999-12-09 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Ray Blaak 1999-12-11 0:00 ` Geoff Bull 1999-12-10 0:00 ` Vladimir Olensky 1999-12-10 0:00 ` Roger Racine 1999-12-11 0:00 ` Geoff Bull 1999-12-10 0:00 ` Vladimir Olensky 1999-12-09 0:00 ` Jerry Maple 1999-12-10 0:00 ` Vladimir Olensky 1999-12-10 0:00 ` Ted Dennison 1999-12-10 0:00 ` Richard D Riehle 1999-12-14 0:00 ` P.S> Norby 1999-12-11 0:00 ` Jeffrey L Straszheim 1999-12-09 0:00 ` Robert Dewar 1999-12-08 0:00 ` Ted Dennison 1999-12-08 0:00 ` Richard D Riehle 1999-12-09 0:00 ` Georg Bauhaus 1999-12-10 0:00 ` Preben Randhol 1999-12-09 0:00 ` Ted Dennison 1999-12-09 0:00 ` Richard D Riehle 1999-12-08 0:00 ` jim_snead 1999-12-09 0:00 ` Ted Dennison 1999-12-09 0:00 ` John English 1999-12-09 0:00 ` Preben Randhol 1999-12-01 0:00 ` ld 1999-12-01 0:00 ` Michael P. Card 1999-12-02 0:00 ` Preben Randhol 1999-12-02 0:00 ` John Duncan 1999-12-12 0:00 ` Ronald Caudill 1999-12-13 0:00 ` David C. Hoos, Sr. 1999-12-13 0:00 ` John Duncan 1999-12-13 0:00 ` Ehud Lamm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox