Business Week (12/6/99 issue) article on Software Quality

Business Week (12/6/99 issue) article on Software Quality

[Michael P. Card]

( 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 ==-----

Re: Business Week (12/6/99 issue) article on Software Quality

[ld]

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
 

Re: Business Week (12/6/99 issue) article on Software Quality

[Michael P. Card]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Michael P. Card]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Preben Randhol]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[John Duncan]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Preben Randhol]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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

 

Re: Business Week (12/6/99 issue) article on Software Quality

[Keith Thompson]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[jim_snead]

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!

Re: Business Week (12/6/99 issue) article on Software Quality

[Robert Dewar]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Ted Dennison]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Greg Martin]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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 

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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 

Re: Business Week (12/6/99 issue) article on Software Quality

[Ray Blaak]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Robert Dewar]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Robert Dewar]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[John English]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Ted Dennison]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Ted Dennison]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Georg Bauhaus]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Jerry Maple]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Preben Randhol]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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
 

Re: Business Week (12/6/99 issue) article on Software Quality

[Roger Racine]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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

 

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Vladimir Olensky]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Vladimir Olensky]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Vladimir Olensky]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Ted Dennison]

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.

Re: Business Week (12/6/99 issue) article on Software Quality

[Preben Randhol]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Roger Racine]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Richard D Riehle]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Jeffrey L Straszheim]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Geoff Bull]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Geoff Bull]

Ray Blaak wrote:
> 
>  a bug is a particular kind of error, namely a programming error.
> 
But, hardware also has bugs.

Re: Business Week (12/6/99 issue) article on Software Quality

[Ronald Caudill]

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!

Re: Business Week (12/6/99 issue) article on Software Quality

[John Duncan]

[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

Re: Business Week (12/6/99 issue) article on Software Quality

[David C. Hoos, Sr.]

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

Re: Business Week (12/6/99 issue) article on Software Quality

[Ehud Lamm]

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!

Re: Business Week (12/6/99 issue) article on Software Quality

[P.S> Norby]

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