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.