This article may be circulated freely as long as the copyright notice is included.
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.):
"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
|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
-- Regional Manager of a large Oakbrook, Illinois,
|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
|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
|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,
|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.|
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.|
Let's examine what we have to do to exploit reuse in object-oriented, procedural, or other languages:
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.
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.
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.
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:
Furthermore, in earlier versions of COBOL, you couldn't pass parameters at all!. Consequently, many early COBOL programmers adopted a style in which the only subroutines were PERFORMed paragraphs which were bound to specific data items in a global DATA DIVISION. Unfortunately, they have passed on that tradition to their younger colleagues, many of whom continue to organize their programs in that way.
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.
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.
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
Last modified January 19, 2008