The Search for a General Reusability Metric

Jeffrey S. Poulin, Ph.D.
Lockheed Martin Federal Systems
Owego, New York

Proceedings of the Workshop on Reuse and the NASA Software Strategic Plan, Fairfax, VA, 24-27 September 1996.


Many researchers have attempted to derive a general reusablity metric for software. Such a metric would quickly tell us the relative ease of using a given software component in new environments. However, deriving this metric requires an objective, repeatable, and quantifiable approach. The answer to this search eludes us because reusability inherently defies these requirements. The reasons for this include (1) the fact that researchers cannot agree on what makes software reusable, which leads to serious practical and theoretical barriers, and (2), the ability to use software depends on the environment as well as the internal characteristics of the software.


We would like a general reusability metric (1) to help us build new reusable components, and (2) to help us identify potentially useful components that already exist, for example, in legacy systems. However, determining what makes software reusable continues to elude researchers and practitioners alike. Most software experts agree that applying general software engineering principles will not only lead to better software, but they will also lead to more "reusable" software. These experts stress guidelines such as encapsulation of data and operations, low coupling, high functional cohesion, good documentation, and thorough testing. However, whereas many reusability researchers stress good software engineering, most also ignore the affects of the software environment on the ability to reuse individual components [Pou94, Pou96].

The search for a general reusability metric faces many of the same challenges as the search for metrics in other related fields. For example:

In the search for a general reusability metric, we must consider several issues that may conflict with our overall goals. For example, if research shows that reusers find small components easier to reuse, should we make all reusable components small? Does this mean we cannot reuse a large component? Would we not prefer to gain the benefits of reusing large components as opposed to small ones? Likewise, if research shows that reusable components have low complexity (as measured by the McCabe or Halstead metrics, for instance), should we limit the complexity of our reusable components? Would we not prefer to encapsulate our most difficult algorithms? Furthermore, how do we account for the situation when some of the reusability attributes we have identified have more importance in determining whether we can reuse a component? Or, more to the point, what happens when one attribute seems highly statistically correlated with our perception of reusability? Why continue our expensive search for a general reusability metric when an easily obtainable measure such as lines of code serves us just as well? Compounding these issues lies the underlying fact that no one really understands or agrees on what makes a component reusable. Many people have identified factors and attributes that tend to make software easier to reuse, but arriving at single, unifying metric that brings these attributes together continues to elude us.

Poulin's Taxonomy of Reusability Metrics

After analyzing numerous methods, we have grouped the approaches into the taxonomy shown in Figure 1. First, we observed that most methods attempt to determine the reusability of a component by examining nothing but the component code. We call these module-oriented. Some methods look at additional pieces of information that have a relationship to the code, such as abstracts, usage instructions, and design documents. We call these component-oriented.

Figure 1: Taxonomy of Reusability Metrics

Second, we observed two major approaches to reusability. Empirical methods stress objective, numerical, and repeatable metrics, such as those obtained by observing the module complexity or size. Qualitative methods included (or even emphasized) subjective criteria, such as how well a module complies with a set of style, certification, quality guidelines, or simply agrees with the opinions of "experts."

Example: In a comprehensive statistical study of a NASA software production environment for unmanned spacecraft ground support software, Selby reports on numerous factors influencing the reuse of software components [Sel89], As part of this study, Selby collected and analyzed reusability attributes on 7188 FORTRAN modules from twenty-five moderate and large size software systems. We classify this as a module-oriented, empirical approach.

Poulin's Common Reusability Model

Each of the methods we examined identified a unique set of attributes to consider as part of a reusability assessment. Each of the methods then attempted to prove, via statistical analysis, experimentation, or other means, that the selected attributes contributed to reusability. We examined we observed some common elements in these searches for a general reusability metric. For example, most empirical methods identified the following reusability attributes:

  1. Reusable modules have low module complexity.
  2. Reusable modules have good documentation (a high number of non-blank comment lines).
  3. Reusable modules have few external dependencies (low fan-in and fan-out, few input and output parameters).
  4. Reusable modules have proven reliability (thorough testing and low error rates).

Qualitative methods often used:

  1. A subjective assessment of how well a module complies with a set of software engineering guidelines.
  2. A set of code standards for modules.
  3. A set of required supporting information for components.


Tracz observed that for programmers to reuse software, they must first find it useful [Tra88]. We stress that the usefulness of a component depends as much on the framework in which it fits as it does on internal characteristics of the component.

Nearly every method we observed meticulously examined the contribution of low coupling, high cohesiveness, modularity, etc., to reusability. Although we agree that these attributes give indications as to the ease of use of a component, they cannot, by themselves, provide a general measure of reusability. Since reusability depends on context, any reusability assessment must consider the affects of factors such as the domain, framework, and software architecture in which the component must operate. Nearly all current reusability metrics fail to include any of these environmental factors.


Software metrics must produce values that preserve our observations about software. Unfortunately, the search for a general reusability metric seeks to put an empirical value on a poorly understood characteristic. To succeed, we need to first agree on what makes a component "reusable."

Most importantly, the ability to reuse software depends on environmental factors that fall completely out of the scope of individual software modules or components. The search for a general reusability metric must consider these environmental factors as well as factors derived from the software. We conclude that although we can determine empirical values for reusability attributes of software, we cannot establish an general reusability metric.

Cited References

Halstead, Maurice H. Elements of Software Science. Elsevier North-Holland, New York, 1977.

McCabe, T.J., "A Complexity Measure," IEEE Transactions on Software Engineering, SE-2, 1976, pp. 308-320.

Poulin, Jeffrey S., "Measuring Software Reusability," Third International Conference on Software Reuse (ICSR'3), Rio de Janeiro, Brazil, 1-4 November 1994, pp. 126-138.

Poulin, Jeffrey S., Measuring Software Reuse: Principles, Practices, and Economic Models. Addison-Wesley, Reading, MA, 1996.

Selby, Richard W., "Quantitative Studies of Software Reuse," in Software Reusabilty, Volume II, Ted J. Biggerstaff and Alan J. Perlis (eds.). Addison-Wesley, Reading, MA, 1989.

Tracz, Will, "Software Reuse Maxims," ACM Software Engineering Notes, Vol. 13, No. 4, October 1988, pp. 28-31.