Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!wuarchive!udel!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: Reasons for low ADT reuse
Message-ID: <6536@hubcap.clemson.edu>
Date: 22 Sep 89 01:09:05 GMT
References: <11928@boulder.Colorado.EDU>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 47

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.

   Consider some of the things that have happened within the
   last few years: there is now a language whose definition
   is an ANSI and international standard which prohibits subsets
   and supersets (ensuring portability), which provides *secure*
   facilities for the construction of quality ADTs (and by that
   I mean limited private types, which can be built such that
   instances of the ADT will maintain consistency in the presence
   of multitasking, and will in fact process requests in parallel
   while ensuring serializability and recoverability, etc. etc.),
   and for which second-generation highly optimizing compilers
   are now widely available.  This language is also saving lots
   of money in practice (as described in the IEEE Software article
   of November 1988, "Large Ada projects show productivity gains"),
   which is stimulating considerable growth in its use.  Finally,
   companies have developed catalogs of components for this language
   (Wizard Software, lib systems, etc.) and are actively selling them 
   into the user market.  In short, the conditions in which the ADT
   approach can thrive are now being established.

   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%); Magnavox expects to increase
   the reuse rate to 25% on the next project, and believes that a reuse
   rate of 50% is possible.

   Bottom line: Reuse is now proving itself.  We are making it happen.

   (By the way, reuse is going to be a major topic at the Tri-Ada '89
   conference up in Pittsburgh, and I will be in an excellent position
   to give recent results as soon as I get back from the conference.)


   Bill Wolfe, wtwolfe@hubcap.clemson.edu