Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!uunet!dino!uxc.cso.uiuc.edu!tank!ncar!boulder!scotth
From: scotth@boulder.Colorado.EDU (Scott Henninger)
Newsgroups: comp.sw.components
Subject: Re: Reasons for low reuse
Message-ID: <11449@boulder.Colorado.EDU>
Date: 7 Sep 89 18:29:53 GMT
References: <11347@boulder.Colorado.EDU> <6392@hubcap.clemson.edu>
Sender: news@boulder.Colorado.EDU
Reply-To: scotth@boulder.Colorado.EDU (Scott Henninger)
Organization: University of Colorado, Boulder
Lines: 85

|>From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
|
|   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").  

To say this is to say that current reuse environments are adequate.  They
are not.  The fact of the matter is that it is easier and takes less time
to code it yourself than reuse existing code with current technology. 
Besides, and I repeat, *people are not aware of what reusable components
exist*.  This is primarily a tools problem, not a training problem. 
Training can only get you so far.  Supporting tools must exist before
people will practice what they are preached.

It should also be noted that the NIH syndrome exists in any design
discipline.  To paraphrase Herbert Simon: "when designing artifacts for
people, *do not postulate a new man*".  The NIH syndrome is simply a part
of human nature.  You, President Bush, or anyone else, ARE NOT GOING TO
CHANGE IT.  Claiming that the "the problem has to be overcome" in this
case makes the critical mistake of trying to change human nature.

|> 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.  

Unfortunately, this is a yet unrealized goal.  The fact of the
matter is that designing generic code is extermely difficult and time
consuming.  And it will NEVER be able to handle all of the cases that
programmers will come up with.  The ability to tailor existing code is
essential. 

|   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.

This is precisely my point.  Whenever people talk about generic code, they
inevitably give examples of *simple* ADTs; ones that you learn in your
freshman programming class.  I would argue that this would constitute an
extermely small percentage of the code for, say, an accounting program, a
user interface, or microcode for a tape drive.  The extreme effort
expended in creating a generic stack, queue, or whatever brings little
savings to one trying to create a real application.


|   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.   

I agree with this in principle.  What we have to avoid is making the
arrogant statement that Computer Science will give us the ability to
formalize all domains; i.e. succeed where others have been "failing" for
tens, hundreds or thousands of years (all the way back to Plato). 
Guillermo's approach of "controlled approximations to *satisfycing*
solutions" is exactly what I'm arguing for.

Let me make a clarifying remark.  I have always stated that the hardware
analogy is *misleading* and is doing a great deal of harm to current thinking
about software reuse.  There are surface similarities, but the problem is
much greater for software.  A hardware engineer can flip through a few
hundred pages of hardware component descriptions and find what he needs. 
Because software is so much more diverse than hardware, the number of
potential components increases by orders of magnitude.  This makes the
problem *fundamentally* different - tools are needed to assist the
programmer.



-- Scott
   scotth@boulder.colorado.edu