Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!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 reuse
Message-ID: <6392@hubcap.clemson.edu>
Date: 5 Sep 89 21:24:56 GMT
References: <11347@boulder.Colorado.EDU>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 57

From scotth@boulder.Colorado.EDU (Scott Henninger):
> | ("Can Programmers Reuse Software?" IEEE Software, July '87, pp. 52-60)
>  
> [...] It is not clear to me that all of the training in the world will 
> solve the problem.  The problem is twofold (maybe more):  First of all, 
> there are potentially millions of components to choose from.  [...] 

   The first problem that has to be overcome is the Not Invented
   Here syndrome; we must have programmers who want to use components.
   This can be addressed by training (at the university level), and
   also by appeal to management (in the "real world").  Incidentally, 
   the hardware analogy is absolutely wonderful for convincing 
   non-technical managers of the value of reuse; they grasp it
   instantly, and immediately become enthusiastic supporters.

> Secondly, once you've got a component, you must tailor it to your 
> specific needs.  This means understanding the code or some description 
> of the code.  Anyone who has debugged code written by others can attest 
> to just how difficult this is.  

   Wonderful reasons for NOT DOING IT!!!  In particular, components
   should be designed in a generic manner, such that the "customization"
   can be done automatically.  As an example, I manage the Clemson Ada
   Software Repository, which contains ADTs like Generic_Priority_Queue 
   (among others).  The user can dream up a new data type, define a few
   simple operations over the type (such as "=" and assignment), write
   a single line of code to do the instantiation, and voila: the user 
   now has a new data type (a priority queue which can manage objects 
   of the user's new type), and a considerable range of powerful 
   operations over that queue, without ever looking at anyone else's 
   implementation code; the entire process takes a grand total of 
   about 5 minutes.
 
> |   Also, regarding the hardware analogy, it does not draw a direct
> |   correspondence between computer software and computer hardware;
> |   rather, it draws an analogy to the extensive catalogs of ICs, 
> |   resistors, capacitors, etc. used by electrical engineers to build
> |   all kinds of application-specific products.
> 
> Again, this assumes that the components can be used without modification.
> This is not the norm with software, but is with hardware.  Also, we must 
> keep in mind that resistors and capacitors implement one kind of machine.
> For software, we must find the equivalents of resistors and capacitors for
> each domain we write software for.

   Resistors and capacitors are domain-independent, and so it is with
   abstract data types such as B+ trees, linked lists, directed graphs,
   etc.; these are the resistors and capacitors of the software profession.

   There are also special-purpose ICs in the hardware industry, and 
   these are the things which must be developed according to the methods 
   described by Guillermo Arango in his brilliant article on Domain Analysis.
   The software equivalent of a special-purpose IC would be a package 
   containing a set of domain-specific data types, functions, and procedures.   


   Bill Wolfe, wtwolfe@hubcap.clemson.edu