Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Message-ID: <34464@athertn.Atherton.COM>
Date: 15 Feb 91 18:19:41 GMT
References: <88431@tut.cis.ohio-state.edu> <6108@stpstn.UUCP> <87829@tut.cis.ohio-state.edu> <6248@stpstn.UUCP> <1991Feb11.103100.112@skyler.mavd.honeywell.com>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 60

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

> But certainly in principle there is no
> reason to believe that your own methods of certifying correctness of
> implementations should be any better than those of, say, an
> independent laboratory that offers its official seal of approval.

The problem is that even if an independet laboratory offers its seal of
approval, you still have to certify it yourself anyway.  There are two
reasons for this.  First, the possibility that your intended use would be
regarded as extreme or abberant by the original designers and laboratory
testers, in which case you will have to test just to verify that this
special case is correctly handled by the purchased object code.  Second,
there is always the possibility that you the purchaser misunderstood what
the vendor offered, and that the product you purchased won't suit your
needs. Since externally it may seem what you wanted, you may not notice
this until you use it. (E.g. you want a character sort routine that uses
ascii sort order, but the one you bought uses "dictionary rules" that sorts
caps and lowercase the same and sorts Mc* as if written Mac*...). 

So it is not the case that the one's own methods are necessarily better
at determining correctness to specification, but rather that they are
more specific for determining applicability to the situation at hand.
We use an object oriented system to do our development and inherit from
objects created by others.  The amount of testing necessary on the INHERITED
CODE boggles people's minds.  Not that the inherited code is necessarily
buggy, but rather not well understood in special circumstances.  By inheriting
a lot, one might be able to create a complex system with a day's coding and
testing on the new module.  But until the developer is completely familiar
with inherited objects there will need to be lots of testing with them!
If no source is available, and no  way to determine branch coverage in
the inherited modules, testing is purely black box and may need to be more
intensive than if the developer could see in and use some white box methods.

This imbalance in the huge reduction of coding but relatively little reduction
in testing astonishes people who assume that testing and coding efforts will
be linearly related.  It can also pose a problem in managing the internal
reward structures of the developers.  Many current  programmers find the
new code development the internally rewarding part, and find testing 
unrewarding work.  They can be frustrated in an environment that reduces
the source of internal rewards and increases the relative amount of 
unrewarding work.  Of course, you could fire the existing  programmers
and hire people with different internal reward structures who will enjoy
the testing work more. From a cold mechanical viewpoint this may seem
fine, but when you consider that there are real people out there already
doing programming work and contributing to the success of their companies,
and that this means huge dislocations for them, you can see that this
is a nasty human management problem, and is quite a challenge for
OO purveyors and supporters who go beyond theoretical benefits and look
into the actual problems of implementation of OO technologies in organizations.

One resulting observation is that perhaps OO technologies will work best not
in CS's most technical inner sanctums, but among end users themselves who
may have very different internal reward structures, career goals  and
desires. 

Scott McGregor
Atherton Technology
mcgregor@atherton.com