Spence Green

A recent software presentation that I saw started with an “architectural discussion.” One slide listed “Object/component-based design” as a feature, which was qualified by the usual platitudes including “Maximizes software re-use.” The slide then made the bold leap to “faster development” as the principal benefit of this “design decision.” I sighed. Two decades after “re-use” entered the technical nomenclature, the term is still misapplied. Re-use remains a misunderstood ideal with more promise than payoff.

Parnas’s 1979 paper, “Designing Software for Ease of Extension and Contraction” responded to four common software objectives:

• Deliver a subset of a system’s features
• Add a simple feature
• Remove an un-needed feature
• Tailor the system to meet changing user requirements.

The common complaint against software here was that such ostensibly jejune objectives became intractable. Parnas began with the surprising description of programs as “abstract mathematical objects.” But mathematicians state and prove theorems, seeking generality. If a mathematician becomes aware of “a set of closely related theorems, he responds by proving a more general theorem.” A good theorem is invariant across instances. We would prefer a commutative property that applied to both addition and multiplication, for instance, over one that applied to only one or the other.

Programmers, on the other hand, respond to a minimal requirements set. Generality therefore has necessary design and construction costs, for that principal is de facto “not minimal” (A performance cost often exists, too). Further, programmers often associate generality with the absence of local invariants such as magic numbers and tight coupling. Real re-use has system-level implications, though.

Parnas suggests dogmatic use of a “uses” relationship between “components” during system specification. The “uses” relationship is of course the intellectual ancestor of composition, a tenet of OO design. Jacobsen defined composition in 1992 as structuring an object–which is a number of operations and a state–by its parts. A family, for example, could be composed of a man, woman, and child (more liberal compositions are of course possible). The “uses” relationship still exists in UML and frequently appears in object diagrams. Furthermore, “real” object-oriented languages such as Ada and Smalltalk make expression of this concept possible. Why then does re-use remain a novelty?

Two principal problems exist. Within a company, the cost of finding a general component is often high. Basic information management issues such as the absence of a centralized repository and poor internal search capabilities are obvious causes. This argument is unspecific, however. The real problem is an instance of the free-rider problem (this is especially true in contracting organizations). Projects are often unwilling to accept the costs associated with generality even in light of the utility realized by both that project and other company groups. “Re-use” therefore becomes a topic of much comment and little consequence. It costs too much.

Re-use works if it is the chief end. Four scenarios come to mind:

• Extensions–This category includes frameworks (eg, .NET, J2EE) and APIs (eg, Ruby on Rails).
• Components–UNIX-style applications that exist as input/output functions. grep is the obvious example.
• Schemas/Ontologies–Here we find XML schemas and interface standards.
• Design patterns*–Popularized by the GoF, concepts such as the Singleton have become the software equivalents of Charles Sanders Pierce’s hobby horse. One paper has shown, however, that patterns are usually mutilated in the process of instantiation, making them hard to “recover.” In other words, patterns do not possess the same order of invariance as mathematical theorems.

The OSS community has been the principal beneficiary of re-use’s promise. An OSS component must exist as an autonomous element on the Internet to gain support, therefore making generality and interoperability key considerations. The absence of formal funding also eliminates the free-riding phenomenon on the developer side.

Re-use has failed as a “silver bullet” in the software industry, and it will continue to do so.