Software Reuse:
Because the Waters are Rising

by Eric Aranow
Context Consulting

Mr. Aranow is the President of Context Consulting and is a principal in The Reuse Group, a group of consultants specializing in reuse-oriented consulting services. Mr. Aranow is a member of the Program Committee for the Object World conferences. He can be reached via email at or on the world-wide web at http://www.reuse.com.

Everybody should be looking at software reuse

For years now, software development organizations have been aware that the "waters" of software problems are rising. They are desperate to find ways to achieve a number of elusive goals: 
     - increased quality
     - reduced time-to-market
     - increased productivity
     - reduced maintenance costs
     - increased customer responsiveness
     - reduced defects
     - reduced risk
     - rapid functional prototyping
     - leveraged technical expertise
     - increased integration
In their attempts to achieve these goals, companies have invested in myriad technological and methodological "solutions", such as CASE tools, OO languages and environments, repositories, and OO and structured methods. Most of these investments have not paid off, and the reason is that each of these merely hint. at the answer. The real answer is software reuse!

Quite a few organizations have been successful with software reuse. Success stories include divisions of HP, AT&T, Verilog, Toshiba, and many others. Organizations have realized reuse benefits such as 900% productivity increases, cycle-time reductions of 70%, and cost reductions of 84%. (Independent Research Study of Software Reuse, September 1994, QSM Associates, Inc., Pittsfield, MA 01201.)

Over the next several years it will become increasingly clear to organizations that reusing software is an essential ingredient for long-term survival. The questions you should be asking yourselves should not be whether to reuse or not, but rather how soon and how to start.

OK. Enough hype. Now for the hard facts.

You won't get reuse without trying

The large majority of organizations I have talked with have held a belief that reuse will come as a by-product of OO development. Without a doubt, the cause of this is that nearly everyone (including the media, product vendors, many conference speakers and many OO consultants) talks about the reuse benefits of OO without any consideration of what it takes to make that reuse happen.

Despite having consulted for and talked with a large number of companies, I have yet to see an organization that has achieved any significant measurable reuse benefits as an automatic by-product of developing with OO, or for that matter, from using any technology, such as CASE or repository.

So to what can we attribute the reuse success stories?

In the context of this discussion, one could view every software development organization as belonging to one of two types:

Type 1) Organizations that are willing to take reuse seriously enough to invest in the discipline, infrastructure, architecture and planning that it takes to make reuse successful; or
Type 2) Organizations that don't take reuse seriously. They invest primarily in technology, languages, development environments, and technology-oriented training. If they are thinking about reuse at all, they are hoping, and maybe even expecting, that it will happen somehow as a result of their technological investments. (...and then a miracle occurs...)
The importance of making this distinction is that it is only companies of the first type that have a chance of achieving the spectacular reuse benefits that are so often touted. The success stories mentioned earlier have invested in discipline, infrastructure, architecture and planning for reuse. Organizations of the second type may be talking about a lot of things, but their reuse success stories are not among them.

The fundamental characteristic that distinguishes these two types is their level of patience. Type 1 has patience for long-term investments, and the ability to see long-term investments through to fruition. Type 2 typically has patience only for efforts that can be completed in 6 months or less.

Software Engineering as Factory-Building

Software engineering is analogous to manufacturing, where one can make the distinction between the patience to invest in a factory as opposed to only in pieces of machinery. The rationale for making the long-term investment in a factory is that the long-range payoff will be far greater than the near-term costs. Imagine where the auto industry would be today if it had never invested in factories! This is where software producers are today without software reuse.

This analogy to factories is remarkably appropriate to software reuse. It takes discipline to design a car model from the components the auto factories are geared up to produce or use. This is nearly identical to the discipline required for designing software that utilizes reusable assets. Similarly the planning required to design a frame, a transmission, or an engine such that it can be used in multiple auto models is very closely related to the planning for reusable software assets, just as the planning to design a factory line such that it can produce parts for multiple car models.

Are you ready for a factory?

Does this mean that if you can't invest in a "factory" then you can't achieve reuse? Not at all! There is more than one path to software reuse. In fact, there are four distinct models of reuse, with different potential benefits, and each organization must be realistic in choosing which it can do:
Ad-hoc reuse - In the completely decentralized, ad-hoc model, reuse is touted as an absrtact goal, but there is no plan, no coordination, and no support from the organization as a whole. This is very easy to achieve, but it rarely makes an observable difference. This is also the only level that doesn't require some funding commitment for longer than 6 months. In the manufacturing analogy, this is like craftsmen designing specialty custom products, but some of them are thinking about ways they can reuse things they have done or seen done before.
Intra-Project reuse - In this model, reuse happens within projects. For the organization, reuse is more-actively encouraged, and there may be central personnel helping to motivate, educate, and assist projects trying to reuse. This takes a bit more effort, but with that effort, some projects may become islands of reuse success. This model could have a chance in a type 2 organization, particularly if the assets being reused have been produced outside the projects. In the manufacturing analogy this is like an assembly line created to produce a single product, using off-the-shelf parts.
Inter-Project reuse - In this model, reuse is encouraged among projects, with central support. There is also a coordinating role, which attempts to bring projects together to facilitate reuse. This requires still more effort and discipline, but the benefits are not restricted to single projects. In the manufacturing analogy, this is like two car models being designed to be built on one assembly line, or like a frame being designed for two car models.
Enterprise-level reuse - In this model, reusable assets are viewed as corporate assets. A reuse-support organization provides architecture coordination and manages asset libraries, and its staff works to ensure that the libraries continue to meet projects' needs. This is the level where reuse best approaches the "factory" analogy. In an auto company, an engine design is a corporate asset to be used again and again in multiple car models, just as is a frame, a transmission or a wheel. New models are designed to utilize as many parts from the "preferred parts list" as possible, which is the way building software with reuse should be viewed.
The third and fourth models require commitment at a level higher than many organizations have been able to enlist so far, and they do require significant upper-management buy-in. At the same time, it is in these levels that organizations begin to achieve the spectacular reuse benefits that lured them to reuse in the first place.

Which path will you take to get to higher ground?

Where to start?

With the "waters" lapping at their ankles, companies cannot afford to dismiss software reuse as being "too hard". On the other hand, it is not likely to be easy.

Managed reuse, in which reuse is built into the software development and maintenance processes, is the key to getting reuse to have an impact on the bottom line. Reuse management is much more important for this than is reuse technology. The technology, such as repositories, catalogs, or sophisticated browsers, will be much more beneficial if the management infrastructure and planning for reuse are sound.

Reuse should never be an end in itself, but rather a means to achieve the goals mentioned in my first paragraph. There may be other efforts in place in your organization working towards these same goals. Organizations working on SEI CMM (Capabilities Maturity Model) level improvement, or Total Quality Management, or Learning Organization efforts (a la Senge's Fifth Discipline) need to fit reuse into those plans, rather than have it compete with them.

If you are a type 1 organization
Your organization is poised to hit the reuse road running. While the other end of the road looks so inviting, it is still a long way off. Even companies that are willing make long-term investments need a coherent strategy to ensure that those investments will pay off.

There are many potential obstacles that could be avoided with the right planning and infrastructure. On the other hand, investing in misdirected discipline, architecture, planning and infrastructure will not help you achieve reuse. And, perhaps worse, if you make investments in the name of reuse but don't deliver, even after the expected learning curve, you could ruin the prospects for reintroducing reuse at a later date. In other words, although you are well poised to take advantage of managed software reuse, it is critical to learn everything you can about growing a reuse program the right way.

As with any long-term investment, you need to be able to reassure the investors that things are progressing according to plan, and this requires an effective feedback loop. Besides reuse management, you will also need to invest in honing your skills at project estimation, measurement, and development process review. You will need to set up an infrastructure that is continuously examining and improving its effectiveness.

If you are a type 2 organization
Your organization is not quite ready to run on the road to managed reuse, but it is still a good idea to start walking. Be realistic about what you can hope to achieve. The reuse benefits will continue to be small until your organization has been convinced to invest in the long term. Until then, you have your work cut out for you just in convincing people to move in the right direction.

Invest in educating your management and developers in both the benefits of reuse and the (realistic) work that it will take to achieve them. Make sure that they are not scared away by pushing exclusively for reuse models that are too sophisticated for them.

Focus on finding commercially-available reusable assets, rather than trying to produce your own. If they are not available off-the-shelf, consider whether it is possible to create a separate asset production group, free from project pressures, to develop these assets. If this is not an option, consider contracting out for their development, so they don't negatively impact projects. Then make sure that the projects know about the assets and how they can make their jobs faster and easier.

The time to start is now

The waters of software problems are rising. Companies that have already reached higher ground know that software reuse is critical to getting there. Regardless of how long the road to managed reuse will be for your organization, you should get onto that road now, because staying put might mean you will soon be under water.

Return to the
Reuse Home Page