Reuse is hardly a new idea. The lowly subroutine was conceived so that the same instructions did not have to be written out each time a particular calculation was needed. Reusable component libraries have been around for almost as long as people have been programming. The first to yield to reuse were math routines, followed soon by input-output. Except for the sheer joy or perversity of doing it, no applications or tool developer writes their own sine-cosine routines anymore.

Then, what is the problem? Unfortunately, most programmers like to program. Some of them would rather program than eat or bathe. Most of them would much rather cut code than chase documentation or search catalogs or try to figure out some other stupid programmer's idiotic work. Software developers develop things; users use them. Other things being equal, programmers will design and build from scratch rather than recycle. All of them are convinced that they can write it tighter or faster or more elegantly than whoever came before. So, even though it might make them more productive, programmers are almost constitutionally biased against reuse. How do we encourage them to change their habits? Suddenly the chorus in the balcony starts singing contrapuntally: “Incentives. Market forces. Rewards schemes. Royalties. Reinforcement schedules. Culture change.” Such lovely cacophony.

It really is not all that hard to understand the score. Reuse on any substantial scale begins with reusable component libraries. There are really only two basic problems involved in such libraries: getting things into them and getting things out again! For programmers to reuse components from a library, there must first be components in the library. Where do these come from?

Various models have been proposed and tried. One is simply to accept free donations from anyone willing to have their code published in the library. Some organizations have had trouble getting donations until they either offered to pay for them or at least promised that authors would not be hounded for maintenance or modification. This approach, a sort of “used-book store” model, appears to be inexpensive, building a large library with little or no direct investment in component development. In theory, components are generated as a side effect of regular development projects.

It does work, but the libraries typically resemble the familiar used-book store. I have spent many happy hours pawing through stacks and boxes of used books, but I think of this more as recreation than as a model for information retrieval or code recycling.

Typically there is little or no quality control and no accountability with this approach. To induce donations, contributing programmers are absolved of responsibility. What you need may be in there, but the odds are against finding it. If it takes the typical programmer more than 2 minutes and 27 seconds to find something, they will conclude it does not exist and therefore will reinvent it.

Components in libraries built with this open enrollment approach are like those thousands of old books of varied vintages and values heaped in disarray. Browsing through the dusty piles for an unexpected treasure can be great fun, but you would not want to do so on a tight deadline. If you know that you need a good current source on post-Soviet economics, you would go to a well-stocked and organized university bookstore, not the basement bookseller with the diverse exotica.

Meilir Page-Jones tells of a client whose “used-book” component library grew so unwieldy that they decided to appoint a reuse librarian whose job it was to keep things out of the component library, letting only the finest become part of the repository. Legend has it that this person became known as Conan the Librarian. For this approach to work, however, there must be substantial forces impelling developers to donate to the library.

Some companies, on the other hand, are biting the bullet of up-front costs and forming groups of full-time developers whose function it is to build components for reuse. These are not typical grunt coders, but highly skilled specialists with a knack for recognizing commonalities, defining abstractions, and building bullet-proof code covering just the right domain. They are rewarded for creating quality components with high potential for reuse. They may even get royalties for each use made of one of their contributions to the library.

If such developers are simply salaried, it could be in their interest to build fancier and more refined components than necessary, since one of the really hard parts of the job is finding what needs to be done. Initially, hundreds of nice little general-purpose components suggest themselves, but as the library grows, seeing what is needed next becomes increasingly difficult. One does not want to finish any one component development project too quickly, because then you either have to become really creative again, or sit on your hands and risk someone noticing you.

Again looking to the book trade for inspiration and understanding, this can be thought of as the “school textbook” model, in which teams of specialists try to figure out what should be taught and how, creating books by committee. Often the results are resplendent with splashy color graphics, tables, exercises, and catchy sidebars on every third page. And they're supported by workbooks, teacher's manuals, supplementary readings, and visual aids. They typically are also uninspired, inelegant, even boring, and all too frequently they are hopelessly out of touch with the real needs of schools and students.

Royalties to the author for reuse pose other problems. For one thing, the feedback provided by royalties, whether paid in cash or merely brownie points, generally comes too late. The money has already been spent, not only on components that see a lot of reuse, but also on ones that proved useless. For any selection process to work, there must be a large pool of parts with substantial variation in “fit” for the selective pressure of the marketplace or environment to work. This means that such libraries will, on the average, always be too big, with a large proportion of mediocre or inferior components from which a small number of “good” ones can be culled. It is hard to know even how the selection process should be driven. Is a widely used component really a desirable one? Perhaps it is so widely used because what is really needed is not in the library. Perhaps its use reflects its position in the index or how it appears in the browser. Perhaps it has simply been better advertised, even though a smaller and more powerful alternative exists.

And what constitutes a use? Each call or instantiation? Each inheritance from or reference to? One program might make 130 uses of a component that is never used in any other project, while another component might find a single use in all 27 systems developed over a year. Which component is more useful? Is a simple and obvious component that becomes widely used worth more royalties to the author than a subtle and ingenious class that saves days of effort on only one project?

Of course, other models are possible. Consider the acquisition specialist in a public library whose job it is to track community interests and needs along with industry trends and keep the collection growing appropriately. Like the used-book store, the public library is built from components (books) that are already extant, are acquired intact, and are entered into the library without further editing or refinement.

For a model better suited to building a reusable software component library we need to look further back into publishing, to the actual acquisition of works to be published. Series editors and acquisition specialists in the publishing industry play an active role in seeking out and developing new titles, working with authors not only in response to sensed needs or demands, but also to round out the “book list” for more complete coverage and to anticipate future needs. This model, or Page-Jones's idea of the “art patron” who not only acquires but commissions works, may be closer to what the software industry needs.

Merely assembling reasonable components does not make a library of reusable components. We have to get developers to reuse rather than reinvent. Many companies are trying to set up bonus and compensation schemes to reward reuse, but I am not convinced that these are necessary for high levels of productive reuse, and they may even be counterproductive in the long run. Sometimes information about performance may be all that is needed. In one organization it was enough to change how they reported programming productivity back to the group. Having invested in the development of a reusable component library, they were disappointed with its limited use. They had been posting monthly bar charts showing programmer productivity in lines-of-code written and delivered. They were persuaded to report instead the total number of lines incorporated into delivered code, which included lines linked from the reuse library. Reuse rose sharply. But is lines-of-library-code the right metric for reuse? Correct, reasonable, and appropriate reuse is probably a much more subtle factor, more difficult to define and measure.

Even if we get the right metric, linking the desired behavior of reuse too directly to tangible rewards may create problems. A close link between simple, quantifiable behavior and direct reinforcement, whether in brownie points or quarterly bonuses, can actually undermine the professional values on which effective reuse is based. As workers conform their actions to fit rational reinforcement schemes, underlying values and attitudes about quality work may actually diminish in salience, increasing the dependence on a finely tuned reward structure.

This is why at one of the three-initialed computer companies, their reusability group is focusing on the corporate climate and culture that shapes reuse and reusability, the common values about programs and programming that impede or advance the sharing of designs and implementations. Perhaps I was lucky to be brainwashed by early mentors who thought it was in their best interest and that of our employers not to keep reinventing the wheel. First in nuclear physics data reduction and later in routine business applications, we built and made extensive use of reusable component libraries. These experiences taught me that, with a rich component library supported by effective tools, the rewards are intrinsic. The payoff is finding the component you need in a reasonable time and then finding that it can be readily used or adapted for your use. Every time this happens, you are being reinforced for it. The habit of initially consulting the library or repository becomes ingrained without being tied to increasing the number of green stamps you get or your quarterly code bonus.

Elaborate gimmicks and extrinsic rewards are probably more important for anemic libraries and clumsy tools than for good ones. Perhaps they signal a need to reexamine the corporate culture itself and the professional values it reinforces or discourages.

From Computer Language Magazine, Volume 9, #7, 1992.