Re: Request for reuse tool info

[dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!wupost!csus.edu!netcom.com !mcgregor@ucbvax.Berkeley.EDU (Scott Mcgregor)]

I would caution that just adding a retrieval tool may not help.  I
have seen a real reuse success situation that happened accidentally. I
saw it later deteriorate when the key thing making it work (a real
living breathing technical librarian who used exhaustive searches
(like grep), simple keyword searches, and a thesaurus of common
synonyms) was replaced with "direct hands on access" by the
programmers using tools.  (I've discussed the details of this case
here in the past--I won't go into it again unless there is interest).

The motivations of the librarian and the programmer are different.
The Librarian feels rewarded when they find something hidden deep in
the library and the patron thanks the librarian.  The programmer may
not share that interest in exploring the library--in fact they may
prefer to write another program from scratch rather than look for one
in the library.  To see if this is true in your organization see how
many programmers consult texts like Collected Algorithms of the ACM in
the library before writing any algorithm.  Do those programmers prefer
to call a librarian (or maybe another peer programmer who might have
needed something similar) or do they prefer to check the card
catalogs, periodical indexes, and browse the stacks?  Past human
behavior is the best predictor of future behavior we have.

I've seen many WELL FUNDED intentional efforts to create such re-use
programs at big companies like HP.  These have never been as
successful as the accidental case I mentioned above.  But these
intentional cases almost always focus on TOOLS, and CATEGORIZATION
schemes. They universally ignore PSYCHOLOGICAL, ORGANIZATIONAL and
ECONOMIC behavior of individuals and groups involved. They never added
a technical librarian to the project as a catalyst, because their
organizations can only hire programmers and write tools. When you have
a hammer every problem looks like a nail.  That limits the reliability
of the structures you can build.

By failing to pay attention to this issue, these efforts almost always
only see the Hawthorne effect--an initial success when the project is
new, and then a decline.  Also, in small pilot groups the
psychological, sociological and economic are known to all participants
and get filtered into the solution in an informal way.  But they ARE
filtered in.  Then when mass deployment occurs there is no one who has
worked out these things for all the new people. The absence of a
formal addressing of these issues means they aren't addressed at all
in the larger case, and this leads to ultimate failure.

Programmers DO reuse a lot of code--namely their own past code. But
when you start to talk about re-using other people's code you need to
consider issues such as whether the new activities are personally
rewarding or whether they will be experienced as de-skilling.  And
since you are talking about multiple people here you need to consider
lessons learned from groupware economics. Individual benefits have to
exceed costs for success--it isn't sufficient that the group benefits
exceed the costs.  

REUSE can be successful, but only if you consider these other aspects.
We would advise potential clients contemplating such a system to look
at these issues and ensure that they are dealt with as well as dealing
with the technical aspects of tools and categories.

-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.