Reuse is seldom attained. It will not come by just by
doing OO. Just as designing good code takes a lot of thought
and effort, so does designing a reuse scheme. The scheme
must consider the art and science of interchangeable parts,
and the human tendencies of authors and of users.
A '96 article by Roland Racko lists challenges for establishing a
corporate reuse program: develop good product which is
needed, make it accessible, and make it easy to find and
use when its needed.
A truly reusable
software component must meet a common
need and must be easily integrated. (Of course it must be
reliable.) "Mining code" might make salient the company's
recurring needs, but the code itself will not be truly reusable.
A reusable component must be deliberately designed as such
and with two goals: broad/common application and
Developing software which has broad and common application
takes experience: the language and its idioms, patterns and
techniques, and knowledge of the corporate need. It also
requires that element of artist
which can be elusive to many
again requires the skill and art of
the developer to pull it off. It also requires corporate-wide
standards (naming and techniques) as well as the enforcement
of these standards so that code can be truly reusable.
) have founded a reuse repository
company. (Just like most web pages...) It's still being
evaluated and improved, but I would like to outline my
scheme for maintaining this repository.
Anybody can contribute to the repository, but you can't
just submit code. An author must also submit support
documentation: a profile
similar to GOF's pattern
descriptions, an example of the code integrated
example of a derived class
(if applicable), and any other
helpful data (such as code used to conduct a unit test
These requirements weed out code that's not well
thought out. They also force the author to think through
how and why someone would reuse this code.
In order to make reusable parts accessible, the code is
kept in a hierarchy of directories on a network. The
support documents and header are maintained in an html
format. When I want to browse for some desired part to
reuse, I start my Netscape browser on the Reuse homepage
and hyper-jump down the hierarchy. Once I arrive at a
component which catches my interest, I can view the
itemized support documents and the header. If I want to
use the component, I download the code to the desired
To help guide the less experienced, certain pages in the
hierarchy provide links to decision or background pages.
For example, our database page offers a link to a page
listing the purposes and trade-off's of various storage
options: data maintained in RAM vs. in a file,
random access vs. lists vs. search trees. While the
experienced developer should know which to use,
these tips are optional guides for those uncertain when
faced with so many choices.
The project is still young, but reuse has occurred many
times now that components are easy to find, they interface
fairly easily, and support documentation accompanies.
Because not just any code goes into the repository,
a contributor has pride in having his component included.
To have a truly functional repository of reusable code,
(I feel) a company needs 
to commit to the effort and
to centralize this effort through one person (or a small
group). This central person should 
be bestowed with
authority and 
possess the required skill, knowledge,
and art to oversee the building and distribution of truly
The type of small group
talks about above is succinctly defined in SucceedingWithObjects
is big on using hypertext to navigate reuse libraries, you may want to check out his book ConfessionsOfaUsedProgramSalesman
Good Luck Randy, it will be hard fun... I too have taken on the role of starting and running a reuse repository.
Would you call this central co-ordinator, a CodeLibrarian?
? :) In my experience, organizations with groups that manage/maintain reuseable (source) code don't limit themselves to libraries -- i.e., they will also manage reusable tools.
For another take, see ExtremeReuseRepository