Path: utzoo!attcan!uunet!decwrl!apple!vsi1!ubvax!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Keywords: Reusability, Division of Labor
Message-ID: <34238@athertn.Atherton.COM>
Date: 1 Feb 91 00:02:40 GMT
References: <87829@tut.cis.ohio-state.edu> <6108@stpstn.UUCP>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 85

In article <87829@tut.cis.ohio-state.edu>,
weide@elephant.cis.ohio-state.edu (Bruce Weide) writes:

> >"Reusability! Why 'reuse' software, when any fool knows it is cheaper
> >to throw used bits away and copy more from a master as needed."
> 
> Seriously, now, have you really faced this sort of response to your
> ideas?  I knew we were having some trouble communicating with certain
> communities, but it never occurred to me that the problems might run
> so deep :-).

Two points.  First, copying more from a master IS a form of reusability.
 One of the things that
makes a "master" masterful is that they are able to churn out good code
real fast.  One trick of the trade
is to keep your old programs, and to copy related sections from old ones
to new ones and begin
modifying rather than writing from scratch.  Code is reused (with
modification), but of course
it is mainly the writer's own limited set of previously written code. 
Such masters also get
through test more quickly too, because they don't feel the need to
re-test the code they had
written before (and re-used with modifications); they feel they only
need to test the modifications
and other new code.  Any "master" who moves from an environment where
they have years worth of reliable
source to a new environment where that old source is entirely useless or
unavailable knows the
sinking feeling of discovering you are less productive than you used to
be.  (Mind you, I don't personally
claim that such reuse is practically equivalent to OO reuse, nor that
the attitude described above about
testing is admirable--I have however often observed many individuals who
do believe so, not merely 
due to trouble communicating with OO folks, but due to different
successful past experiences.

The second point is that a "problem" with OO for many existing
programmers is that it changes the
nature of development in a way that is often annoying to existing master
programmers.  In particular,
when you create a new object that inherits a lot of methods from a deep
class hierarchy, your testing
problem become significantly more complex.   You should test all the
inherited methods, which might number
orders of magnitude more than your number of new methods.  You must test
these inherited methods not simply
because they might be misimplemented in a way that only your new object
uncovers, but also because while you
may have thought you understood their behavior from reading the manual,
their actual behavior may
be different--due to a misunderstanding on your part.   Of course this
is a problem with reusable
components in general, not a failure limited to OO technology
implementations. Unfortunately, the kinds
of personality traits and interests that might be likely to make one
successful generating new
solutions to programming problems may not mesh well with the kind of
traits and interests that
will lead to success in such rigorous testing of other people's code--a
problem that I have personally
observed.  This illustrates a difficult and interesting
non-technological issue for project managers 
in the software industry who choose to adopt OO or other high-reuse
technologies.


Scott McGregor
Atherton Technology
mcgregor@atherton.com

P.s. Lest anyone misattribute various prejudices to me, let me point out
that I have been managing
S/W developers in various OO and other reuse technologies for many
years, and I continue to expect
to do so.  I think that various benefits of reusability are desirable,
but that these technologies
are not without their costs too, particularly as you consider the
developers as humans with
individual desires, goals, and skills rather than as  mechanical
interchangeable resources.  A challenge
I set for myself is to try to find a balance that gets a fair amount of
the technological benefits 
without significant human cost.  Success has varies with different cases.