NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/4968

Text File | 1992-12-15 | 8.5 KB | 174 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!spool.mu.edu!wupost!csus.edu!netcom.com!mcgregor
From: [e-mail] (Scott Mcgregor)
Subject: Re: Request for reuse tool info
Message-ID: <[e-mail]>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 15 Dec 1992 06:59:57 GMT
Lines: 163


Several people have emailed me for more information about an article I
posted here in the past concerning a case of reuse that I had seen
that involved a technical librarian.  The volume of requests seems
high enough to justify posting here, especially since mail
connectivity to some requestors seems to be difficult.  I apologize
for the length, but respondants seem to want many more details, and I
couldn't find a way to tell this story more consisely.  Sorry.

Re-used text starts here:

Unfortunately, I can't reveal names under the terms
of the confidentiality agreement that I signed, even though this is
now ancient history.  Hope it is useful anyway.

In the late '70s a software firm that I consulted for was doing a lot
of projects in FORTRAN and COBOL.  One of the rules they had was that
all subroutines in their shipped products had to be QA'ed and then put
into a company subroutine library (aka directory). There was also a
requirement that there be a comment block filled out by the programmer
at the front of each subroutine, describing the parameters and what
the program did.  Other than this, there was no formal reuse library
requirements. QA was responsible for "managing" the library which
amounted to checking in new subroutines as products were released, and
replacing others as bugs were fixed and code updated, no more.

One of the QA engineers left the company and QA was short handed.
Because of the company's financial situation at the time, management
would not approve hiring someone from outside, though it did approve
transfers from other departments of existing employees.  The QA
manager published an internal openning req, and one person applied,
one of the company technical librarians who had just finished a
computer programming class at a local community college.  While this
person's skills weren't what the QA manager wanted, the QA manager
figured that some employee would be better than none. So he hired the
technical librarian. He gave her the least technical (and from their
perspective least desirable) task: maintaining the company software
subroutines library.  However, the librarian's view of her new job was
different from what QA had done in the past--she really took the
librarian part of the job seriously.

In another interesting turn of fate, the librarian's office was the
first office on the hall after you entered the building.  So every
programmer walked past her office on entering the building in the
morning and after lunch, on leaving for lunch and at the end of the
day, as well as anytime they wanted to go to the restroom, or to the
employee lounge and lunch room.

In an apparently organic way, programmers started to ask her if she
knew of any date routines in the library or other common subroutines
they might reuse.  She would promise to get back to them by phone in a
few minutes or as they returned from lunch, etc.   Then she would
search the directory (i.e. the library) for potential matches and keep
a list of the names, and they passed that on to the interested
programmer. At first only subroutines that the programmers were sure
existed were solicited, but over time they became more varied and
detailed.

At the same time, some organic changes were taking place in the
programming groups.  The programming department tended to operate in
self-managed teams. Management didn't create any job differentiation
between programmers.  However, once the use of the library started to
grow a spontaneous job differentiation occured.  Programmers in teams
started to divide some design tasks among themselves according to
individual programmer preffernces.  People who preferred to
research the library and develop alternative designs that maximized
re-use, did so, while people who wanted to do "clean sheet development"
worked on writing subroutines for areas where there were no
alternatives. Some projects achieved 90% reuse while 40-60% was
common.

Because programmers were thankful for the help of the librarian and
liked her, they created tools to help her.  These included key word
search tools, and exhaustive search (grep-like) tools.  They also
created a thesaurus tool for her. This simplified her work.

After approximately three years, reuse levels and profits were way up.
Then the librarian left the company. The company was doing well then,
so QA was allowed to replace her with a skilled programmer from
outside the company. Since the new replacement wasn't particularly
interested by "librarian work", and because all of these tools were in
existance, it was decided that no librarian was needed and that programmers
could just invoke the tools themselves.

Re-use started to plummet substantially and quickly.  The block comments that
programmers wrote weren't very good until improved by the librarian,
often using the thesaurus program. Now they had to be individually
checked.  Pretty soon they were back to where they started in
productivity. Things didn't get set up right and programmers started
to only retrieve what they had contributed.

I asked the librarian why she thought there was a difference.  She
said that the big difference was that she liked researching in the

but wide library and others did not. She thought of the library as this shallow
but wide swamp that she would wade out into, grab a handful of mud
bring it to the edge and wash it off, and then programmers would say
"Thank you, thank you, thank you!!! Gems! Gems! You are terrific".
This was very rewarding to her.

But when the programmers took over doing the access themselves they
saw it differently.  When I explained the swamp analogy to one he
replied, "Yup, that's right--the library is this big muddy swamp. You
have to wade out into it and go through all this muck.  Who needs it,
I'll just sit on the shore and construct my own solution from
scratch!"

In short, many programmers didn't feel rewarded by searching through
libraries and re-using code.  Such activities were "de-skilling"
compared to the more enjoyable tasks of writing new code. So, when
people were busy they didn't do these or didn't do them well.  This
wasn't intentional sabotage, nor malicious compliance, it was just
people doing what they liked more intently and letting slip what they
didn't like.
A
I found that the success of the program (and subsequent failure) was
dependent upon the roles that people played, their particular values
and how the tasks they worked on fitted the tasks they like.
A
I've since noted that CS programs tend to discourage library research
and reuse of existing designs, whereas other engineering programs such
as civil engineering are just the opposite, and failure to reuse a
known truss design could be considered a problem.  I think this tends
to act as a filter that discourages people with certain values and
encourages others, and in particular it discourages people who enjoy
library research.  You can see this in the lower level of library use
you see among software developers vs. hardware developers in company's
I've worked at like HP.

Someone planning  a reuse program might think intently upon
using human support like technical librarians and take careful
consideration as to how to make it easy for developers to talk with
these people.  They might also consider intentionally hiring a new
team of programmers with a particular pro re-use set of personal
values.

I could go on in more detail, but that would probably be more
appropriate for a consulting engagement.  Interested parties should
contact me off-line at one of the addresses below:


Scott L. McGregor        [e-mail]
President            tel: [phone]
Prescient Software, Inc.    fax: [phone]
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.

--

Scott L. McGregor        [e-mail]
President            tel: [phone]
Prescient Software, Inc.    fax: [phone]
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.