From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!sp.unisys.COM!BENNETT
From: BENNETT@sp.unisys.COM.UUCP
Newsgroups: comp.lang.ada
Subject: reusability
Message-ID: <8703141928.AA20877@ucbvax.Berkeley.EDU>
Date: Fri, 13-Mar-87 16:53:00 EST
Article-I.D.: ucbvax.8703141928.AA20877
Posted: Fri Mar 13 16:53:00 1987
Date-Received: Sun, 15-Mar-87 04:32:40 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

Having just read the two dissertations on reusability
submitted by Mr. Berard, I find myself wondering about a
couple of things.

First, it seems to me that the Cost-Plus-Fixed-Fee contract
is not, in itself a barrier to the development and use of
reusable software.  On the contrary, by making optimum use
of reusable modules, I could reduce the level of effort
needed for implementation and apply the savings on the front
end of the life cycle.  The net effort would be the same,
but we have reason to believe that increased effort on the
front end of the development will lead to a higher quality
output.

Second, I would like to see some evidence that "object
oriented" methods are better than "functional decomposition"
at facilitating reuse.  It seems that it would be the job of
the designer in either case to recognize those functions or
objects which are candidates for reuse.  I might be
convinced if there were a rigorous methodology for either
functional decomposition or object oriented design which
would result in two different designers producing identical
designs from the same input.

Third, requiring that "every piece of code produced for a
project, be relevant specifically to that project" does not.
in itself, preclude implementing reusable modules.  If
modularity and cohesion are emphasized, it is certainly
possible to construct modules (packages, subprograms, ...)
that, while they may not be able to be moved intact from one
application to another, would need very little to refit them
for a different application domain.  We must be flexible
enough in our definition of reusability to accommodate the
range of legal and procedural impedimenta.

If the mountain will not come to Mohammed ...   Let's start
finding ways to use what we have.  Let's get everyone up to
the level of the current software engineering technology. 
Let's quit generating excuses and start attacking the
problem.

                               Michael P. Meier
                              (My opinions are my own ...
                               standard disclaimer)