ReuseRepository

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 
convenient interchangeability.

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
technical people.

''Interchangeable software'' 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.

-----------------

I (RandyCarey) have founded a ''reuse repository'' at my 
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'', an 
''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 
directory.

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 ''[1]'' to commit to the effort and 
''[2]'' to centralize this effort through one person (or a small 
group). This central person should ''[3]'' be bestowed with 
authority and ''[4]'' possess the required skill, knowledge, 
and art to oversee the building and distribution of truly 
reusable software.

---------------------------------------------

The type of ''small group'' that RandyCarey talks about above is succinctly defined in SucceedingWithObjects.

WillTracz 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.

-- ToddCoram

----

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.

-- AnthonPang

----

For another take, see ExtremeReuseRepository