From: johnb@searchtech.com (John Baldwin)
Subject: Re: Do Software Engineers Actualy Do So Badly?
Organization: Search Technology, Inc.
Date: Mon, 12 Oct 1992 15:59:41 GMT


Connor Cahill's responses to Mr. Bushell are well taken, and bear
repeating and expanding.  I've inverted the list from Mr. Cox's book
and address each item...



  TB> Software used as delivered:           2%
                    ^^^^^^^^^^^^
  CC> 1. does this only include custom software?  If so, then it is
  CC>    automatically cutting out a major component in software 
  CC>    purchases made by the govt.

I believe this value, if it refers only to custom software.
Even when software development occurs smoothly, and the Requirements
and Design Specs don't change, it is STILL a difficult process to
make sure the real world requirements are completely captured in
a document.



  TB> Software used after change:           3%

Assuming this value is correct, it is a reflection of the results of
my paragraph above.



  TB> Software abandoned or reworked:      19%
                            ^^^^^^^^
  TB> If I read this right, only 5% of software written for Uncle Sam
  TB> before 1979 was ever used.  That seems a little extreme, but food
  TB> for thought, nonetheless.

Assuming neither category above is zero (otherwise, why mention
both?) then the percentage of software used is: 3% < x < 22%

My assumption is that the difference between "software used after
change" and "software reworked" is that the former was delivered and
then the delivered source code was modified somewhat (either by the
original developers or by another party), while the latter represents
substantially a start-over of the development of the deliverables.



  TB> Software delivered but not used:     29%

  CC> 2. How much of the work was for prototypes that were not intended
  CC>    to be delivered, but rather used for deciding if the project
  CC>    could go forward.

  CC> 3. How much of it was for software research as opposed to a 
  CC>    specific application.  You don't expect to have a 100% 
  CC>    recovery factor for research.

I wish I had real statistics to offer here, but I don't have the time
to look them up (basic laziness notwithstanding :-)).  Proof-of-
concept software and other research products comprise a good fraction
of the code that is delivered to the government.  It is used in some
sense during demonstrations and project reviews, and the research
people get some good papers out of it --- but the code doesn't get
executed on any kind of regular basis to perform useful work.

If we use the broader definition of "use", then  32% < x < 51% 



  TB> Software paid for but not delivered: 47%

Even taking all my above comments into account, this is still a scary
number.  :-(



Finally:

   CC> We have been building bridges for millennia, and planes for close 
   CC> to 100 years.  If you go back to the early stages of either of those
   CC> two engineering disciplines, I would bet that you find that there were
   CC> many more failures than there are today.  

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

   CC> I do agree with this sentiment entirely.


As do I.  We don't have as much time as the aviation field did to
develop reliable engineering techniques; fortunately, we have the
advantage of being able to "skim" off from other fields.  Software
may not be developed the same way that manufacturing works, but if
you come across a good idea, USE IT!  No matter where it came from.

Maybe the President should copy JFK and initiate a "Software
Engineering Race:"

	  Six-Sigma Reliable Software Before the Century is Out!



-- 
John Baldwin                                        johnb@searchtech.com
Search Technology, Inc.                             uupsi!srchtec!johnb
4725 Peachtree Corners Circle, Suite 200            johnb@srchtec.uucp
Norcross, Georgia  30092   USA