Path: utzoo!attcan!telly!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!ames!ncar!boulder!scotth
From: scotth@boulder.Colorado.EDU (Scott Henninger)
Newsgroups: comp.sw.components
Subject: Re: Reasons for low ADT reuse
Message-ID: <11963@boulder.Colorado.EDU>
Date: 22 Sep 89 15:52:31 GMT
References: <11928@boulder.Colorado.EDU> <6536@hubcap.clemson.edu>
Sender: news@boulder.Colorado.EDU
Reply-To: scotth@boulder.Colorado.EDU (Scott Henninger)
Organization: University of Colorado, Boulder
Lines: 77


|>From scotth@boulder.Colorado.EDU (Scott Henninger):
|> The ADT approach has been around for a long time, so I ask you, 
|> why is it not currently practiced?  Don't tell me that training 
|> is the answer - programmers are already trained to design and 
|> implement ADTs.
|
|>From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
|   You want results?  From the article cited above: Magnavox did a
|   Ada project at the 1.2-million-line level in which reuseable
|   software NOT developed on the project was not counted at all,
|   and reuseable software developed on the project was counted only
|   once; the productivity was 550 lines per man-month for the systems
|   software and 704 lines per man-month for the applications software.
|   The average productivity found in a productivity consultant's database
|   of 1,500 projects at the 1.2-million-line level was only *77* lines per
|   man-month.  Reuse saved 190 man-months (9%) of effort and reduced
|   the schedule by two calendar months (4%); 

Although I am truly happy these managers were able to find ways to claim
productivity gains (and probably get promotions for it), we should be
skeptical of these numbers for many reasons, two of which follow:

  1) Cobol could probably do better by the lines-of-code measurement. 
     In other words, just because more lines of code were developed
     doesn't mean that productivity was enhanced.

  2) Different projects have different dynamics.  It is a fallacy to
     compare man-months of projects that simply had the same number of
     lines of code.  First of all, 1) still applies.  Secondly, the
     difficulty of the domain is not accounted for.  Thirdly, the skills
     of the programmers is not accounted for; ad infinitum.  You can't
     compare apples to oranges! 

|   Magnavox expects to increase the reuse rate to 25% on the next
|   project, and believes that a reuse rate of 50% is possible.

General Electric claimed the same thing in the 60's.  It never
materialized.

The bottom line is that there is a distinct possibility that these
results are contrived by self-serving interests.  I think you're right
in stating that reuse is making headway, but it is extremely small, and
is certainly much smaller than the results you cite indicate.  

I characterize it as a monkey climbing a palm tree to reach the moon. 
He sees he is making progress and begins to make wild claims. 
Unfortunately, he soon reaches a dead end.  I claim the dead end in
software reuse is cognitive overload.  It will take thousands or
millions of components to make a truly useable software reuse
environment.  There is no way that a human can keep track of what is
available at that kind of scale.

The cognitive overload also comes in understanding what a component does
for you.  Do you realize how hard it is to get novice programmers to
understand what a stack does?  And this is one of the simplest
constructs in computer science.  Just think of training someone to
understand 1000 ADTs (that are much more difficult to understand than
stacks) to the point that he can (re)use them. 

I also must emphasize that the problems of reuse ARE LANGUAGE
INDEPENDENT.  Even with all of the religious followers of ADA out there,
you will never in a million years convince me that ADA is anything more
than trivially different from Pascal, C, Algol, etc.

|   [...] there is now a language whose definition is an ANSI and
|   international standard [...]

Emerson said that "a foolish consistency is the hobglobin of little
minds...".  In this spirit, I would claim that we do not know enough
about human factors in programming (note that I did not say programming 
*languages*) to point to standards as a means to claim that your favorite
language is the best. 


-- Scott
   scotth@boulder.colorado.edu