Reusable Components -- Decades of Misconceptions, Guidelines for Success
© Conrad Weisert, Information Disciplines, Inc., 12 September, 2000

This article may be circulated freely as long as the copyright notice is included.


Unclear on the Concept

Since well before the "structured revolution" of the mid 1970s we've known that a library of reusable components is the single largest contributor not only to programming productivity but also to the quality of the resulting application software. Nevertheless, only a minority of organizations have managed to exploit heavy reuse.

Today component reuse remains surprisingly controversial. While nearly everyone concedes that its benefits are impressive in theory, some hold that reuse is too hard to implement to be of practical value to most organizations. Others mistakenly believe that the choice of programming language is critical to being able to exploit reuse.

Below is a sampling of such views spanning more than three decades. Although mature professionals may laugh at the naieveté of the claims from the 1960s and 1970s, a new generation has come along to make equally silly assertions. (I've withheld the names to avoid embarrassing the authors.):

Misguided Assertion

Comment

"Since Java is reusable . . . a lot of the low-level architecture that you had to rewrite over and over again for project after project is already done."

-- an ISP CEO, quoted in Information Week
July 17, 2000, p. 94.

Of course, object-oriented languages facilitate and encourage reuse by encapsulating knowledge of function logic with knowledge of related data representation. Consequently C++ and Java have stimulated a recent reawakening of interest in reusable components. The speaker, however, naively assumes that Java somehow automatically assures reuse. It doesn't. Worse, he believes that other languages prevent reuse. Any programming language that supports clean coupling among separately compiled components is suitable for developing reusable components.

A mature programmer would be ashamed to admit rewriting low-level modules over and over on project after project using any mainstream programming language.

"Our clients pay us to develop software,
not to find it."

-- Regional Manager of a large Oakbrook, Illinois,
software development firm, December, 1995.

We doubt that the speaker wants his clients to know about his aversion, which surely adds to their costs and to the vendor's revenue (but probably not to profit).
"We tried on one project to develop potentially reusable code, but it ended up adding significantly to the cost of the project, and none of our other projects ever used any of those components. We concluded that re-use just isn't worth the effort."

-- President of a software development firm specializing
in client-server application architecture, 1992.

Re-use will never occur automatically. It must be strongly supported by management and by the organization's methodology and project culture.

Furthermore, if developing potentially reusable components really did add much to the cost of development, it's almost certain that the software design would not otherwise have been of sufficiently high quality to assure long-term maintainability.

"Reusable components are well suited to scientific programs, but business applications are each so unique that it's impossible to capture much meaningful commonality for reuse."

-- Manager of applications programming
in an aerospace company, ca. 1973.

That was a common misconception in the 1960s. Experience repeatedly showed, however, that typical business applications presented even more reuse opportunities than scientific ones.
". . . Frankly this is more modularity than you really need in business systems. There just aren't that many common routines that can be incorporated without alteration. If two programs are accessing the same file they are doing different processing. If they are doing essentially similar processing, the file descriptions will be different. It would hardly make sense to describe the master inventory and the payroll master identically so that identical logic could be used to update them!."

-- letter to the editor, Datamation,
November 1970, p. 10

That one took the prize for the most unenlightened letter of 1970. The writer obviously lacked experience in separating abstract patterns from concrete parameters, a fundamental and essential programming skill. He was so used to mixing together the knowledge of input-output logic with the knowledge of the content and structure of a record that he couldn't imagine how one could treat them separately.
"That 1 was really interesting, and the next time I run into a problem that lends itself to that approach I'm going to try it."

-- A business-applications programmer in a large chemical company, 1966.

I have yet to encounter a business application problem that does not lend itself to that approach.

How do We Reap the Benefits of Reuse? Five Guidelines for Success

Let's examine what we have to do to exploit reuse in object-oriented, procedural, or other languages:

  1. The software development organization must support a component repository (formerly called a central module library), to which programmers will contribute new components as by-products2 of their projects, and from which other programmers will draw existing components for use in their projects. Such organizations ought to include university computer science departments,3 who should be setting an example for their students.

    A librarian must be designated to oversee the administrative aspects of the repository. Larger, more formal organizations may also choose to establish a review process for contributions. Although that may keep the repository from getting cluttered with ill-advised or poor-quality components, it also poses the risk of delay in making useful components available.

  2. The repository must be indexed and the components documented, so that the effort required to locate, understand, and incorporate a component is less than the effort required to develop a comparable one from scratch.

    The indexing scheme need not be elaborate and does not require a hierarchical classification. Experience shows that a simple permuted keyword index of descriptive titles is adequate.

  3. The organization's programming standards must call for the use of certain components in certain common situations. Those components may come either from the organization's own repository or from vendors' libraries.

  4. Quality assurance or walkthrough reviews of new application systems should note and question missed opportunities

    As a general guideline, every non-trivial software development project should contribute two or three new components, and, once the repository is mature (100-200 components) less than half the code in a new application should be developed specifically for that application.

  5. Quasi measures of productivity based on quantity of new code written and tested must be eliminated. Let's reward our programmers when they solve a problem without writing custom code.

Do Language-Specific Obstacles Exist?

We noted above that Java is not the magic key to reusability. We must concede, however, that a few mainstream programming languages do make reuse harder than it should be. In particular:

Even those obstacles can be circumvented by knowledgeable programmers, and, of course, today's huge repertoire of available languages and tools presents many practical alternatives to COBOL and Visual BASIC.

Getting it Done -- Management Discipline

The five guidelines listed above call for parts of an organization's software development infrastructure or methodology. They will not spring into existence on their own. Although the details and the actual components will arise largely "bottom-up" through voluntary contributions from the staff, the framework has to be established "top-down" by decisive action on the part of programming management.

Furthermore, once the framework is in place, management must continue to support all five of the guidelines for success.

Heavy software component reuse makes a huge contribution to the productivity of every programming project and to the quality of every software end product. If management sincerely believes that, then they won't be tempted to withdraw support in the face of a tight target date or a budget squeeze.


1—A presentation on modular program organization and reuse.
2—At little or no cost beyond the cost of good design in the first place.
3—I know of none that currently does.


Related material on this web site

Reusable components: Will object-oriented technology finally break down the barriers? -- A presentation abstract.

IDI Course MG-08: Establishing and Administering an Effective Central Reusable Component Library -- a single-session seminar.

If It Ain't Broke, Fix It Anyway—a retrospective on major methodology breakhroughs over four decades.

Return to IDI home page
technical articles
methodology information.

Last modified January 19, 2008