Making the Reuse Business Work
Jacobson, Griss, Jonsson, IEEE Computer, Oct 97, pp36-42
If we take 15% as an approximation of the current rate of "passive" reuse
that individual engineers achieve anyway and 90% as the figure more than a
few organizations are achieving ...
Myths and misconceptions:
- Developers will select the components they will reuse from tens of
thousands of small components.
- Setting up a library of reusable components will itself induce developers
to reuse them.
- Paying application developers to contribute components to the repository
will build up the library.
- Paying application developers to use components from the repository will
encourage reuse.
- Adopting OO languages will lead to systematic reuse.
- Architecture does not have to be addressed as a specific task.
- Reuse changes are too risky.
Change is risky in the near term, but failure to change is "too" risky in the
long term.
Systematic reuse cannot be adopted piecemeal.
Systematic reuse is hard because at least five factors have to be interwoven
and mastered:
- vision
- architecture
- organization and management
- financing
- software engineering process
Levels of complexity that demand that architecture preceed reuse:
- Small, well understood, application built by 1 or 2 programmers
- Large system attacked by groups of teams
- A family of application systems
- Component systems that are reusable throughout the family
- Add variability mechanisms to the components
- Expectation of long term return and leverage
In the past, architecture was not recognized as a separate function.
Reuse requires coming to terms with specific planning for architecture.
Architecture requires a separate team headed by a broadly experienced
developer, assisted by the best people available.
Architecture requires time.
Getting the architecture right is one of the reasons it takes several years
to move a reuse business into the black.
Once the architecture is defined, it takes a smaller team to monitor its
relevance and support modifications.
There has been a tendency to assume that the existing organization
structure, given a few statistics on the benefits of reuse to motivate
it, and given some technical training on the mechanics of reuse to
empower it, could go forth and practice reuse. This approach has not
been successful. One of the reasons is that existing software
development is organized on a project basis. Systematic reuse rests on
an organization structure adapted to its needs:
- An organization unit to capture application family requirements and to
specify architecture
- An organization unit to create the reusable components
- Organization units roughly similar to former project engineering groups
- An organization unit to perform component support, project support, sys
admin, and housekeeping chores
- All four units report to a single manager
A rather lackadaisical reuse program in which a few indifferent
creators provide a few components that developers don't much care for
is not going to pay off. Reuse is not a "faith" that one hopes to
spread. It is a business in which the company wishes to make money.