The idea of reusing systems and software engineering assets—such as requirements, designs, source code and test cases—has long been the leading candidate for discontinuous improvements in engineering efficiency and quality. Douglas McIlroy first introduced the idea of reusable software components as a means to injecting engineering principles into software development back in 1968. Research on the broader topic of reuse illuminated huge opportunities during a spike of activity in the late 1980s and early 1990s. More recently, the field of product line engineering has focused on lucrative opportunities for reuse within a family of similar products or systems.
Reuse in concept is simple, clear and powerful. Reuse in practice, however, has been messy, muddled and anemic. The problem is, the things about reuse that seem obvious don’t work, and the things about reuse that work aren’t obvious.
This has resulted in many different engineering organizations predictably taking the same ruinous path to failed reuse initiatives, while consistently overlooking the readily available path to reuse breakthroughs. Not only has this stifled the field of systems and software reuse, but it has also unnecessarily stunted the growth and advancement of entire companies and industries.
This contrast in perspectives on reuse—the seemingly obvious things that don’t work versus the things that do work that aren’t so obvious—can be succinctly stated as: Reuse is an Event, Sharing is a Journey.
Reuse is an Event
Central to the most ineffective forms of reuse is the idea that reuse is an event. Unfortunately, this is also the first impression most people have about reuse, and this misperception sticks. The classic example is when an organization creates a library for reusable assets. The reuse event occurs when someone finds and reuses an asset from the library for a new or enhanced product or system. High fives all around.
The reuse event provides 100% reuse on day one, but 0% reuse every day after that. After N different reuse events from a library asset, there are N copies of the asset, plus the one in the library. Enhancements, variations or fixes on any of these N+1 copies results in divergence. To reconcile and consolidate this divergence requires a level of effort that is proportional to N2. That is, a change to any of the N+1 copies must be reconciled with the other N copies, or N+1 times N.
Now we can start to see the problem with treating reuse as an event. For N reuse events, we get savings that are proportional to a linear N, but thereafter, throughout evolution and maintenance, we incur costs that are proportional to a polynomial N2. Not a good balance, particularly considering that the effort and cost for the maintenance phase of a system typically dominates the upfront creation effort and cost.
Forms of reuse that fall into the anemic reuse-is-an-event category include clone-and-own (new systems built by cloning, modifying and maintaining copies of previous system assets), reusable asset libraries, the Lego-block software component analogy, and Software Product Line approaches based on separate domain engineering (building a library for a domain) and application engineering (copy-based reuse events from the library).
Sharing is a Journey
Key to the most effective forms of reuse is the idea that sharing is a journey. Reuse in this case is not an event experienced in isolation, but rather an odyssey embarked upon with others over time. Unfortunately, this is a rather non-intuitive perspective that on first impression sounds like it might be more trouble than it’s worth.
The sharing approaches to reuse are generative in nature, where shared assets are automatically compiled, assembled or otherwise configured into systems through some type of abstract specification. A classic example might be the Java Swing library, where commonly used GUI widgets can be reused by including the interface specifications and parameter settings into a Java program, and then compiling. An example in a more narrowly scoped context might be feature-based product line configurators that select and configure shared product line assets into different company-specific product or system families, based on the specification of features and capabilities that are needed or not needed in any particular system.
In contrast to reuse events, sharing is long-term, and that’s what enables success. Reconsider our example of maintaining N different systems that use the same asset, but this time through sharing rather than reuse events that create N different copies. Enhancements, variations and fixes are now done once in the pre-generator form of the asset, so that the N users can all automatically regenerate the new and improved asset from their previously created specification.
The evolution and maintenance of the shared asset is now centrally coordinated for all N users, so there is a linear N cost for the initial use of the asset and a linear N cost for evolution and maintenance. This provides very effective lifetime amortization through cost sharing across the N products and it allows N to grow very large.
What to do?
The contrasting reuse perspectives have put us into a bit of a quandary. Reusing systems and software engineering assets (requirements, architectures, designs, software, tests, documentation) are always the best candidates for discontinuous engineering improvements that lead to discontinuous business benefits.
However, the reuse-is-an-event approaches that seem obvious don’t work, while the sharing-is-a-journey approaches that do work aren’t obvious. There’s no simple answer to get us out of this quandary other than to educate. We must all become mentors to promulgate these ideas within our organizations and industries, and to create new mentors who can do the same.
Charles Krueger is founder and CEO of BigLever Software, which sells Gears, a software product line engineering tool and life-cycle framework.