What About Reuse?
The best way to attack the essence of building software is not to build it at all. Package software is only one of the ways of doing this. Program reuse is another. Indeed, the promise of easy reuse of classes, with easy customization via inheritance, is one of the strongest attractions of object-oriented techniques.
As is so often the case, as one gets some experience with a new way of doing business the new mode is not so simple as first appears.
Of course, programmers have always reused their own handiwork. Jones says,
Most experienced programmers have private libraries which allow them to develop software with about 30% reused code by volume. Reusability at the corporate level aims for 75% reused code by vol-
ume, and requires special library and administrative support. Corporate reusable code also implies changes in project accounting and measurement practices to give credit for reusability.
W. Huang proposed organizing software factories with a matrix management of functional specialists, so as to harness the natural propensity of each to reuse his own code.
Van Snyder of JPL points out to me that the mathematical software community has a long tradition of reusing software:
We conjecture that barriers to reuse are not on the producer side, but on the consumer side. If a software engineer, a potential consumer of standardized software components, perceives it to be more expensive to find a component that meets his need, and so verify, than to write one anew, a new, duplicative component will be written. Notice we said perceives above. It doesn’t matter what the true cost of reconstruction is.
Reuse has been successful for mathematical software for two reasons: (I) It is arcane, requiring an enormous intellectual input per line of code; and (2) there is a rich and standard nomenclature, namely mathematics, to describe the functionality of each component. Thus the cost to reconstruct a component of mathematical software is high, and the cost to discover the functionality of an existing component is low. The long tradition of professional journals publishing and collecting algorithms, and offering them at modest cost, and commercial concerns offering very high quality algorithms at somewhat higher but still modest cost, makes discovering a component that meets one’s need simpler than in many other disciplines, where it is sometimes not possible to specify one’s need precisely and tersely. These factors collaborate to make it more attractive to reuse rather than to reinvent mathematical software.
The same reuse phenomenon is found among several communities, such as those that build codes for nuclear reactors, climate models, and ocean models, and tor the same reasons. The communities each grew up with the same textbooks and standard notations.
How does corporate-level reuse fare today? Lots of study; rel-
atively little practice in the United States; anecdotal reports of
more reuse abroad.
Jones reports that all of his firm’s clients with over 5000 programmers have formal reuse research, whereas fewer than 10 percent of the clients with under 500 programmers do.26 He reports that in industries with the greatest reuse potential, reusability research (not deployment) “is active and energetic, even if not yet totally successful.” Ed Yourdon reports a software house in Manila that has 50 of its 200 programmers building only reusable modules for the rest to use; “I’ve seen a few cases—adoption is due to organizational factors such as the reward structure, not technical factors.”
DeMarco tells me that the availability of mass-market packages and their suitability as providers of generic functions such as database systems has substantially reduced both the pressure and the marginal utility of reusing modules of one’s application code. “The reusable modules tended to be the generic functions anyway.”
Reuse is something that is far easier to say than to do. Doing it requires both good design and very good documentation. Even when we see good design, which is still infrequently, we won’t see
the components reused without good documentation.
Ken Brooks comments on the difficulty of anticipating which generalization will prove necessary: “I keep having to bend things even on the fifth use of my own personal user-interface library.”
Real reuse seems to be just beginning. Jones reports that a few reusable code modules are being offered on the open market at prices between 1 percent and 20 percent of the normal development costs.27 DeMarco says,
I am becoming very discouraged about the whole reuse phenomenon. There is almost a total absence of an existence theorem for reuse. Time has confirmed that there is a big expense in making things reusable.
Yourdon estimates the big expense: “A good rule of thumb is that such reusable components will take twice the effort of a ‘one-shot’ component.” I see that expense as exactly the effort of productizing the component, discussed in Chapter 1. So my estimate of the effort ratio would be threefold.
Clearly we are seeing many forms and varieties of reuse, but not nearly so much of it as we had expected by now. There is still a lot to learn.
Learning Large Vocabularies—A Predictable but Unpredicted Problem for Software Reuse
The higher the level at which one thinks, the more numerous the primitive thought-elements one has to deal with. So programming languages are much more complex than machine languages, and natural languages are more complex still. Higher-level languages have larger vocabularies, more complex syntax, and richer semantics.
As a discipline, we have not pondered the implications of this fact for program reuse. To improve quality and productivity, we want to build programs by composing chunks of debugged function that are substantially higher than statements in programming languages. Therefore, whether we do this by object class libraries or procedure libraries, we must face the fact that we are radically raising the sizes of our programming vocabularies. Vocabulary learning constitutes no small part of the intellectual barrier to reuse.
So today people have class libraries with over 3000 members. Many objects require specification of 10 to 20 parameters and option variables. Anyone programming with that library must, learn the syntax (the external interfaces) and the semantics (the detailed functional behavior) of its members if they are to achieve all of the potential reuse.
This task is far from hopeless. Native speakers routinely use vocabularies of over 10,000 words, educated people far more.
Somehow we learn the syntax and very subtle semantics. We correctly differentiate among giant, huge, vast, enormous, mammoth; people just do not speak of mammoth deserts or vast elephants.
We need research to appropriate for the software reuse problem the large body of knowledge as to how people acquire language. Some of the lessons are immediately obvious:
- People learn in sentence contexts, so we need to publish many examples of composed products, not just libraries of parts.
- People do not memorize anything but spelling. They learn syntax and semantics incrementally, in context, by use.
- People group word composition rules by syntactic classes, not by compatible subsets of objects.
Fred Brooks, The Mythical Man-Month, pg. 222