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
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
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
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
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
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].
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
Metrics Calculator that implements the metrics. If you need
to sell reuse to your management, use metrics!
[Bauer93] Bauer, Dorothea, "A Reusable Parts
Center," IBM Systems Journal, Vol. 32, No. 4, 1993,
[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.