Re: Bugs or Mistakes?

Re: Bugs or Mistakes?

[MaryAnn Atkinson]

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

Re: Bugs or Mistakes?

[Richard D Riehle]

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
  
 

Re: Bugs or Mistakes?

[Nick Roberts]

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

Re: Bugs or Mistakes?

[M.]

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.

Re: Bugs or Mistakes?

[Larry Kilgallen]

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

Re: Bugs or Mistakes?

[Vladimir Olensky]

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

Re: Bugs or Mistakes?

[Vladimir Olensky]

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

Re: Bugs or Mistakes?

[Robert Dewar]

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.

Re: Bugs or Mistakes?

[Richard D Riehle]

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  

Re: Bugs or Mistakes?

[Robert Dewar]

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.

Re: Bugs or Mistakes?

[Robert Dewar]

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.

Re: Bugs or Mistakes?

[Ted Dennison]

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.

Re: Bugs or Mistakes?

[Robert I. Eachus]

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...

Re: Bugs or Mistakes?

[Richard D Riehle]

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

Re: Bugs or Mistakes?

[Robert I. Eachus]

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...

Re: Bugs or Mistakes?

[Richard D Riehle]

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

Re: Bugs or Mistakes?

[Marin Condic]

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/

Re: Bugs or Mistakes?

[Robert Dewar]

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.

Re: Bugs or Mistakes?

[Michael Stark]

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