From: bushell@fox.nstn.ns.ca (Tom Bushell)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: NSTN Network Operations Centre, Nova Scotia, Canada
Date: Sat, 10 Oct 1992 04:01:12 GMT



In the article that started this whole thread, Ken Magel asks:

>Do Software Engineers Actually Do So Badly?           
>
>      Many articles here and in the popular press bemoan the
>"fact" that software engineering does not do anywhere near as
>well as other more mature forms of engineering in delivering
>completed products on time and within budget.  However, I
>recently was involved in two incidents involving other forms of
>engineering which indicate that every form has similar
>difficulties.
>There is a new interstate interchange being constructed about a
>   
>    (deleted description of examples of civil engineering
>     schedule delays)
>

If by "Software Engineers" you mean the people who collectively
produce software (a group that probably includes most of the
people reading this news group - us), regrettably, the answer
seems to be "Yes, we're doing very badly indeed".

I'm quoting the following statistics from DeMarco and Lister's
"Peopleware" book from memory (just today, I forced my copy on my
new boss, claiming that it's the Bible/Koran/Talmud for managers
of software projects - hope he reads it!) but I think they're in
the ballpark:

     "30% of all software projects fail - they're abandoned
     before completion, or if delivered, are not fit for use"

     "50% of all projects costing more then $750,000 fail"
     [as I recall, Peopleware provided the project size in man-
     years - I made some salary assumptions and translated]

If anyone can quote the actual numbers, please correct me.

This is scary enough, but I also went back through my file of
articles saved from this very newsgroup, and came up with the
following gem:

--------------

>Newsgroups: comp.software-eng,comp.object
>From: gregor@cs.tu-berlin.de (Gregor Engelmeier)
>Subject: Software costs revisited?
>Message-ID: <1992Jul20.120345.26472@cs.tu-berlin.de>
>Sender: news@cs.tu-berlin.de
>Organization: Technical University of Berlin, Germany
>Date: Mon, 20 Jul 1992 12:03:45 GMT
>Lines: 26

In Brad Cox's book: "Object Oriented Programming" from 1986, he
quotes an inquiry carried through by the U.S. Government
Accounting
Office in 1979, in which a breakdown of software costs versus
actual
results is performed (FGMSD-80-4). The results at that time were:

Software paid for but not delivered: 47%
Software delivered but not used:     29%
Software abandoned or reworked:      19%
Software used after change:           3%
Software used as delivered:         2%

.
.
.

---------------------

If I read this right, only 5% of software written for Uncle Sam
before 1979 was ever used.  That seems a little extreme, but food
for thought, nonetheless.

Now, I don't know about you folks, but I find this extremely
alarming.  I have first hand experience with the uncertainties of
software development - a few years back I worked on a project 
that was originally estimated at $1M, and (I'm told) actually
cost closer to $4M when it finally went into production, at least
a year late. (My standard joke when I tell this story is to
hurriedly claim that I was only _personally_ responsible for $1M
of the overrun :-). Also, I heard someone who worked for the
developing organization describe their standard development
process as: "1) Go to a bar and scratch some requirements on the
back of a napkin.  2) Sign a fixed price contract.  3) Start
development.")

On the bright side, at least it was in the happy minority of
projects that do ultimately succeed.  Those of you who in Canada
or the US that get Weather Now/The Weather Channel can see this
box in action - it's the system that draws the computer graphics
for the local forecasts between the live broadcasts.  It was this
project that convinced me that I had been basically flying by the
seat of my pants for the first few years of my career, and it was
time to develop a little more rigor.

Anyway, while other engineering disciplines have their failures,
they seem much less frequent than in software development.  30%
of all bridges don't collapse, and 50% all planes don't crash -
even the prototypes.

I'm not sure that a direct comparison between "Software
Engineers" and other engineers is fair, however.  I read an
article a year or two ago (in IEEE Software, I think) where the
author had studied the history of other engineering disciplines. 
She said they tended to evolve in three distinct steps:

   1) Craft 
   2) Commercial Practice
   3) Engineering, based on a scientific foundation

She concluded that we were just making the transition from craft
to commercial practice.  So maybe we don't have to be _too_ hard
on ourselves - it's early yet.  But we damn well better work hard
towards that goal of true engineering.  It's our professional
responsibility - modern society is becoming too dependent on
computers for anything less to be acceptable.

-Tom Bushell (future Software Engineer - for now I'll just
              pretend)