1: Introduction

Over the past years, many reports have appeared that describe both positive [e.g., Henry95, Rosenbaum95] and negative [e.g., Glass98] experiences with software reuse. As one of the companies that led the introduction of software reuse into mainstream software development [Bauer93, Lenz87], we have made many observations about the theories of software reuse and what will actually work in practice. Key among these observations lies the fact that to successfully introduce a formal reuse program into an organization, management must support reuse both with words and with the necessary resources.

However, before management will allocate resources, they need to see a business case. After all, "business decisions drive reuse!" [Poulin97a]. To build a business case, the reuse advocate must have uniform, realistic, and easy to understand reuse metrics. Not surprisingly, even conservative applications of these metrics will show very impressive returns on reuse investments. As a result, we have repeatedly used our reuse metrics as a technology insertion tool and we firmly believe in the critical role that they play when selling software reuse to management.

2: A Simple Matter of a Business Case

We believe in "truth in metrics." Realistic and honest assumptions combined with a simple, easy to understand business model provide all the necessary evidence to sell reuse to management.

Our model starts by asking "how much effort could you save by reusing something rather than writing it yourself?" The answers might span a wide range, usually from 50-100%, and depend heavily on factors such as the environment and type of application. Based on a plethora of hard data, we find a reasonable savings due to reuse to lie right around 80% (allowing 20% effort for locating, understanding, and integrating the reused components). At an industry average cost to develop new software at around $100 per line, a Development Cost Avoidance of 80% will get management's attention every time.

Second, we point out that reuse allows the manager to continue to avoid cost over the entire life of the product. In our environment, we have centralized support for our reusable components. So if reusable software has a bug, reusers can have it fixed for free (not counting the hassle). Although we can estimate maintenance costs many ways, we happen to do it by multiplying our known historical error rates by what it costs us to fix those errors. For example, if one of our managers reuses 1000 lines of code and historically would expect to fix three errors in that code at a cost of $5k per error, our manager would estimate a $15k maintenance savings from reusing that code. This Service Cost Avoidance helps further sell the idea of reuse to the manager.

Adding these two values (Development Cost Avoidance and Service Cost Avoidance) results in an impressive total Reuse Cost Avoidance (RCA). RCA represents the approximate total benefits of reuse. However, the astute manager will ask "what about the costs to write reusable software in the first place?"

We admit that making software reusable takes more effort than writing software solely for one-time use. This effort goes into making a more generic design, conducting additional testing, and actually writing useful documentation. We ask the manager to estimate how much effort this ought to take. As before, the answers span a wide range from 0% to about 300%. Based on considerable hard data we suggest a good approximation (again, depending on many factors) to actually lie around 50% extra work. So, for every reusable component that the manager invests in, it will cost 50% more to build than if they had built it for one-time use. Therefore, reusable software costs $150 per line rather than the industry standard of $100 per line.

In short, the business case for reuse consists of avoiding 80% of the development costs for everything the manager could reuse (plus some additional maintenance savings) minus the 50% extra it cost to build the reusable components in the first place. Q.E.D.!

This business case leads to an amazing revelation; with these conservative assumptions, the manager will break even with as little as two reuses! Therefore, if the manager has two related projects, it pays to base them both on the same foundation of reusable components. This simple business case allows the manager to easily see how reuse significantly reduces costs!

3: The Necessary Warning Label

Although our metrics make a lot of sense, the paragraphs above make some assumptions. First, if an organization does not have two customers for a component we do not recommend putting any extra effort into making it reusable. Many organizations fall into the trap of "build it and they will come." Organizations should instead only make reusable investments in software that it knows applies to several projects.

Second, we assume that the organization has some general experience with software metrics. It will require significantly more effort to implement reuse metrics in an organization that does not have any software metrics than to incrementally add them to an established metrics-driven software management process.

Third, we assume that the organization knows its own abilities; in short, that the organization knows how much it costs to write new code and it knows the quality level of that code. Although we can build a business case using our suggested values ($100 per line of code, 80% savings to reuse, 50% additional work to write for reuse, etc.), an organization would ideally use their own values for these parameters.

Finally, deciding "what to count" as reuse always comprises the most difficult challenge in implementing a reuse program. Without this definition, the values provided in the business case have no meaning. For an overview of this most critical issue, see [Poulin97b].

4: Conclusion

Our metrics have proven enormously effective in helping to sell software reuse to management. They take only a few minutes to explain and despite very conservative assumptions will show a powerful financial incentive in support of reuse investments. To assist in developing a business case and conducting "what if" scenarios, we have provided a simple JavaScript Reuse Metrics Calculator that implements the metrics. If you need to sell reuse to your management, use metrics!

References

[Bauer93] Bauer, Dorothea, "A Reusable Parts Center," IBM Systems Journal, Vol. 32, No. 4, 1993, pp. 620-624.

[Glass98] Glass, Robert L., "Reuse: What's Wrong with This Picture?," IEEE Software, Vol. 15, No. 2, March/April 1998, pp. 57-59.

[Henry95] Henry, Emmanuel, and Benoit Faller, "Large Scale Industrial Reuse to Reduce Cost and Cycle Time," IEEE Software, Vol. 12, No. 5, September 1995, pp. 47-53.

[Lenz87] Lenz, Manfred, Hans Albrecht Schmid, and Peter F. Wolf, "Software Reuse Through Building Blocks," IEEE Software, Vol. 4, No. 7, July 1987, pp. 34-42.

[Poulin97a] Poulin, Jeffrey S., Measuring Software Reuse: Principles, Practices, and Economic Models. Addison-Wesley, Reading, MA, 1997.

[Poulin97b] Poulin, Jeffrey S., "Reuse Metrics Deserve a Warning Label: The Pitfalls of Measuring Software Reuse," Crosstalk: The Journal of Defense Software Engineering, Vol. 10, No. 7, July 1997, pp. 22-24. URL: http://www.stsc. hill.af.mil/CrossTalk/1997/jul/reuse.html

[Rosenbaum95] Rosenbaum, Susan and Bertrand du Castel, "Managing Software Reuse- An Experience Report," Proceedings of the 17th International Conference on Software Engineering, Seattle, WA, 23-30 April 1995, pp. 105-111.