🚀 go-pugleaf

|>From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
|Subject: Re: Reasons for low reuse
|Date: 5 Sep 89 01:21:47 GMT
|
| ("Can Programmers Reuse Software?" IEEE Software, July '87, pp. 52-60)
 
So we must ask ourslves - Do we want to "train" people to become successful
reusers, or should we provide adequate support for reusing software.  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.  No one could possibly keep track of all of them.
Support for retrieving useful components is therefore needed.  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.  The
"conceptual closeness" measures devised by Prieto-Diaz are a first step in
trying to assess the modifiability of a component.  One could also argue that
conceptual level (as opposed to implementation level) descriptions are needed
(no, current documentation techniques are not sufficient).

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

|   It seeks to diminish the "art form" mindset, replacing it with "engineering
|   discipline".  

To claim that this is true is to claim that all the world's domains can be
reduced to engineering principles.  While it's a worthy goal, I'm not so sure
that it can be done.

I would like to hear other opinions.  Anyone out there?
-- Scott
   scotth@boulder.colorado.edu