While many companies justify their investment in object technology by citing productivity gains realized from systematic reuse, few have seen productivity increases. Software development economics don't generally justify reuse. Without reuse, why bother with object technology?

Ask most people why they are interested in object technology and more often than not the answer will be reuse. Nearly a decade ago, Electronic Data Systems performed an experiment in which they redeveloped a manufacturing system that was originally written in PL/1. A team of Smalltalk programmers received the same specifications and test suites as the PL/1 team had been given and proceeded to replicate the manufacturing system. The results were impressive. The original PL/1 system consisted of over 265,000 source lines of code (SLOCs), required 152 staff months of effort, and took more than 19 calendar months to develop. The Smalltalk system consisted of 22,000 SLOCs, required 10 staff months of effort, and took only 3.5 calendar months—overall, a 15-fold improvement in productivity, attributed to the systematic reuse of software components (see David Taylor’s Object Oriented Information Systems: Planning and Implementation, John Wiley and Sons, 1992).

Even though these numbers may appear inflated for everyday developers, this was still powerful stuff in the hands of managers desperately looking for a technological solution to cope with their project backlogs. It made sense that developers should construct programs from pre-built components rather than handcrafting programs line by line. The electronics industry, which assembles new products from component catalogs, is often cited as the model the software industry should emulate. Brad Cox coined the term Software (IC) Integrated Circuit to describe this new style of software construction (see Brad Cox’s Object Oriented Programming: An Evolutionary Approach, Addison-Wesley, 1986). Corporations began investing huge sums in retraining and retooling to adopt object technology, often using the economics of reuse to justify the investments.

A decade later, we have reusable frameworks for creating user interfaces, and reusable libraries for network communications, and data storage, but few components for creating applications. In general, applications are still handcrafted. We certainly have not seen an order-of-magnitude increase in productivity, and, in fact, we’ve been lucky to just get a few percentage points of annual productivity improvement. Reasons often given as to why we have not seen widespread systematic reuse in the software industry range from “You’re using the wrong language,” to the “not invented here” syndrome, to the final catch-all excuse, “lack of management support.”

I don’t believe these reasons fully explain why we do not see widespread reuse in software development. Most programmers and managers enthusiastically want to embrace systematic reuse—but in truth, the economics of software development work against its adoption.

What Is Reuse and What Is Reusable?

First of all, what do I mean by “reuse?” If you ask five programmers what reuse is, you’ll get eight different answers. I like Will Tracz’s definition in Confessions of a Used Program Salesman: Institutionalizing Software Reuse (Addison-Wesley, 1995): “Software reuse is software that was designed to be reused.” Note the emphasis on the phrase “designed to be reused.” This distinguishes software reuse from software salvaging, reusing software that was not designed to be reused. Many people regard salvaging as reuse, because they avoid rewriting code by salvaging classes and functions from existing applications. This form of opportunistic reuse is definitely beneficial to the software development organization, but it is not the systematic reuse that industry pundits had in mind.

What most pundits (especially Brad Cox, when he proposed Software ICs) were envisioning was integrating reusable components—pre-built, fully encapsulated software—into our applications the same way that hardware engineers integrate chips into boards. When the order-of-magnitude productivity improvement predictions were made, the predictors were thinking in terms of software components that had been especially designed for reuse.

This was a lovely idea and, with the widespread adoption of object-oriented programming languages, one whose time had come. Yet today, most cases of reuse are actually software salvaging. Despite many who say reuse has not reached its full potential because programmers are opposed to it, I firmly believe most programmers would readily embrace reuse. Thus, the forces opposing reuse are not due to programmers’ fear of change, nor to programmers’ notoriously large egos. For many software development organizations, reuse simply may not make economic sense.