Software Reuse - Facts and Myths

Kevin D. Wentzel

Hewlett-Packard Laboratories
1501 Page Mill Road, Palo Alto, CA, 94303, USA
[email protected]

Abstract

The concept of systematic software reuse is simple: the idea of building and using "software
preferred parts." By building systems out of carefully designed, pre-tested components, one will
save the cost of designing, writing and testing new code. The practice of reuse has not proven to
be this simple however, and there are many misconceptions about how to implement and gain
benefit from software reuse.

This panel brings together several researchers and practitioners of software reuse to discuss
what they see as some of the most important facts and myths about software reuse.

1 Introduction

Software is constantly increasing in its importance in product development. Currently at
Hewlett-Packard Company, approximately 70% of our engineers do some software development.
In many products, it is now software that provides the competitive advantage. This is true both in
computers and in products like laser printers and oscilloscopes which don't look much like
computers. Systematic software reuse is a key business strategy that software managers can
employ to improve their software development processes, to decrease time-to-market and costs,
and to improve product quality.

The concept of systematic software reuse is simple: the idea of building and using "software
preferred parts." By building systems out of carefully designed, pre-tested components, one will
save the cost of designing, writing and testing new code. In practice, there are many technical,
process, economic and organizational issues to overcome. However, several companies find that
reuse does work, and can payoff handsomely with high levels of reuse. There are significant
corporate reuse programs at AT&T, HP, IBM, GTE, NEC, Toshiba, and others. They see major
improvements in time-to-market, quality and costs[l].

To be successful, a reuse program requires much more than just reusable code modules and
library technology. Careful consideration must be given to the way reusable workproducts are
designed and packaged, to the architecture and framework in which reusable workproducts are
combined, and to organizational and economic structures.

2 Facts and Myths about Reuse

Because reuse is such a simple concept, we have found many misconceptions about it in
discussions with software developers and software engineering researchers. The panelists are
expected to explain what they view as the most important facts and myths about reuse. I've
explained a few of my own below.

2.1 Libraries

One very common myth about reuse is, "The larger your software library, the more reuse you
will achieve."

While code library use is common and helpful, most libraries handle only low-level, generic
parts, leading to low levels of reuse. In many cases, libraries are built by collecting pieces of
potentially reusable code from existing applications and from new developments without enough
emphasis on standards for quality, documentation, architecture, and testing. Current library
research is focused on classification, library tools and library interoperability.

To get high levels of reuse and consequent high levels of benefits, one needs more than just code
or object libraries. One needs to deal with the careful design of reusable architectures and
components that fit together for particular domains and with the systematic introduction and
institutionalization of reuse in the development organization. In several of the successful reuse
programs we have found, there are a very small number of reusable components however these
components are architected to work together to make up a sizable percentage of a delivered
system. In these systems the architecture is carefully designed to allow additional functionality to
be added for features not covered by the reusable modules. A library management system is
unnecessary in these reuse programs.

2.2 The software development process

Effective reuse is not a simple addition to existing software development processes. The
systematic application of software reuse will dramatically change the software process [3]. Two
of the most important changes are:

Changes in the way software entities will organize themselves to produce and consume
reusable software workproducts. Effective software reuse needs a clear division among
the roles of producers of reusable workproducts and consumers who use them to build
applications. Changes in management and support structures are needed to support the
new roles. Changes in the way developers are evaluated and rewarded may be required to
reinforce the new roles.

Changes will be made in software development models, methods, processes and
technologies to take advantage of reuse. Applications will no longer be designed
independently, one at a time. Instead, conscious effort will be made (Domain
Engineering) to design reusable assets for a range of expected applications and new
applications will be designed to take maximum advantage of the available software
preferred parts.

2.3 Reuse payback

When a reuse program is started, the organization needs to have appropriate expectations on
when a return on the investment will be realized. Reuse has proven to be a long term investment
showing benefits over a series of projects often spanning several years [4]. When a short term
payback is expected, disappointing early results can cause a program to be canceled before it has
a chance to pay off. Benefits of a reuse program are more than cost savings on projects. Benefits
of earlier time to market and of decreased long term maintenance costs must also be taken into
account when evaluating a reuse program.

Since reuse changes roles and organizations and may require new organizational structures,
funding the production, use, and maintenance of components can be a thorny issue in today's
business environment. The reuse producers may not be attached to a particular profit producing
project and can be viewed as a cost center. This leaves them vulnerable to cuts when budget
adjustments must be made.

3 Reuse research at Hewlett-Packard

HP Laboratories started a multi-disciplinary software reuse research program in 1992 to
complement HP's Corporate Reuse Program [1,2]. An integrated approach to technology,
method, process and organization issues is key to our research program.

The research has two major theme: domain-specific kits and flexible software factories. The
domain-specific kit research focuses on the technologies and methods for the production use and
support of kits for application development, while the flexible software factory work
concentrates on the processes, organization design, economic issues, and software engineering
and communication infrastructures for kit-based software development.

We are testing the ideas of domain-specific kits and flexible software factories through a series
of prototypes and pilot projects in Hewlett-Packard product divisions.

References

[1] Martin L. Griss, John Favaro, and Paul Walton. Managerial and Organizational Issues -
Starting and Running a Software Reuse Program, chapter 3, pages 51-78. Ellis Horwood,
Chichester, GB, 1993.

[2] Martin L. Griss. Software reuse: from library to factory. IBM Systems Journal, 32(4):1-23,
November 1993.

[3] Martin L. Griss and Kevin D. Wentzel. Hybrid Domain-Specific Kits for a Flexible Software
Factory. In proceedings: SAC'94, Phoenix, Arizona, March 1994.

[4] J. E. Gaffney and R.D. Cruickshank. A General Economics Model of Software Reuse. In
proceedings: 14th ICSE, Melbourne Australia, May 1992.


Facts and Myths affecting Software Reuse

Victor R. Basili Institute
for
Advanced Computer Studies and Department of Computer Science
University of Maryland College Park, Maryland 20742

For this panel, we were asked to discuss what we thought were the three most important facts or
myths affecting reuse. I believe there is a great deal of misunderstanding about reuse in the
software domain and it is difficult to pick out only three, but I will try.

Fact 1: There has been too much emphasis on the reuse of code.

There are an enormous variety of 'experiences' that can be reused, other than code. These include
product artifacts, such as design, architecture, requirements, user's manuals and test plans;
processes such as life cycle models, methods, and techniques, and other forms of experience
such as cost models, baselines of defect classes, etc. Sometimes, reuse of some objects, e.g.,
product architectures, directly enable the reuse of others, e.g., code. Sometimes the reuse of some
experiences, make it difficult to use others. For example, it is difficult to reuse a code module in
an object oriented design that was developed using functional design. The ability to reuse implies
some form of domain analysis has been done to identify the appropriate contexts for reuse of the
particular object under consideration.

Fact 2: Software reuse implies some form of modification of the artifact being reused.

When trying to reuse any form of experience, some form of modification is typically required to
adjust the object to the context in which it will be used. The simplest case is where the
modification is the substitution of a parameter, e.g., the square root(x) and we typically consider
this verbatim reuse. But most cases are more complex; the basic framework can be reused but the
parts need to be changed, e.g., the format of a requirements document can be reused but most of
the requirements are new. The goal is to maximize the amount of information reused. However,
if we view the reuse decision as a binary switch, verbatim reuse or not at all, then we have
minimized our opportunities for reuse.

Fact 3: Software development processes do not explicitly support reuse, i.e., in fact they
implicitly inhibit reuse

If reuse of an artifact requires modification, Who does it, who pays for it, and when does it get
done? There is an implication that someone must package artifacts to make them reusable. This
is hard to do during project development, where the goal is to get the product out the door in the
shortest time possible. Thus, other resources (time, people, money) must be expended to package
artifacts to maximize their potential for reuse. These activities include the analysis,
generalization, tailoring, and formalization of existing experiences and must not be on the critical
path of the project.

One such option is to create an organization whose role is to analyze and synthesize experiences
for reuse. On the other hand, the development processes themselves need to be defined to take
advantage of these reusable artifacts. i.e., searching and modifying experiences on-line, during
project development, must be supported by the appropriate processes and sufficient resources.
The reuse of experience has not been fully incorporated into the development or maintenance
process models.

Software Reuse Experience at Hewlett-Packard

Martin L. Griss
Hewlett-Packard Laboratories
1501 Page Mill Road Palo Alto. CA 94301-1126
[email protected]

At Hewlett-Packard, we have had visible divisional software reuse efforts since the mid-1980s.
Most of these efforts were started with the goal of reducing time to market, improving software
productivity, or improving product consistency. In 1990 we initiated a multi-faceted Corporate
Reuse Program to gather information about reuse from within HP and from other companies. As
we studied the existing reuse programs, we discovered that certain issues were poorly
understood, and as a consequence, mistakes were made in starting and running certain programs
at HP and elsewhere.

Our corporate reuse program focused on packaging best-practice information and guidelines to
avoid common pitfalls. We also developed technology transfer and educational processes to
spread this information and enhance reuse practice within the company. In 1992 we launched a
multi-disciplinary research program to investigate and develop better methods for domain-
specific, reuse-based software engineering.

We have learned that for large-scale reuse to work, the problems to overcome are mostly non-
technical. Reuse efforts that focus only on building a library, and worse, on f1fSt building a
library system, will not achieve their goals. Achieving high-orders of reuse requires a paradigm
change, leading to the creation, management and use of persistent software assets. This links
previously independent project lifecycles into a laboratory- or organization-wide process.

Management support is critical - reuse is not a "grassroots" effort. While many engineers feel
that reuse is just a technical problem, and so can be handled informally, the process and
organization change required to assure that high-quality software components is produced can
only be funded by a concerted, dedicated management effort. Furthermore, it will take several
years to build up the experience and asset base, and high-level management support is essential
to sustain the commitment. Management, with the support of a process improvement team and
reuse, must integrate people, process and technology issues.


Software entities must think about how they are organized, and how work is partitioned. Often,
managers will say "produce that product, and on the way, produce components too." This rarely
succeeds. Careful consideration must be given to the way reusable workproducts must be
designed, packaged and managed. We advocate a distinct component producing organization, or
at the least, a component support organization, that can take candidate (potentially reusable)
software and carefully package, document, and certify them. Only then will users feel the
confidence to build their products using these components.

The kind of kit methods and technology and the kind of organization and processes needed
should be based on the specific business situation, such the stability of the application domain,
what business issues (such as time to market, conformance to standards, interoperability) drive
the factory. Economics models and metrics must be developed, adapted and deployed to ensure
that the right goals are addressed. For example, overall development productivity (cost savings),
appears less significant than the cost savings attributed to improved quality and decreased
maintenance.

This seems like a lot of work, just to achieve reuse. Fortunately, one does not need to go all the
way in one giant step. We believe that one can choose an investment level, based on experience,
to get an increasing number of benefits. An incremental adoption strategy will include several
steps. such as: Leverage or Cloning; Black-box Code Reuse; Broad Workproduct Reuse;
Architected Reuse; and. Systematic Software Reuse. As one moves from step to step, we get
increased benefits. Each step should be tested with a pilot project before widespread deployment.

Our research and pilot work includes the development and study of formal adoption processes,
domain-specific kits, business modeling, organization design, and technology infrastructure for a
flexible software factory.

Software Reuse Myths Revisited

Will Tracz
Loral Federal Systems Company Owego. NY
[email protected]

It has been six years since the author published the paper Software Reuse Myths in ACM
Software Engineering Notices [tracz87h]. This short paper comments on these "myths" in light
of recent technology advances.

Myth #1: Software Reuse is a Technical Problem

Three major non-technical impediments to reuse have diminished somewhat over the last six
years. There has been some consensus building efforts focused on coming up with standard
definitions for reuse and reusability. The RIG (Reuse Interoperability Group), for example, is
attempting to come up with standards for reusable components and their interchange through
common library access methods. Furthermore, recent efforts within the DoD to change
government acquisition policies will further stimulate the industry. Finally, with copyright law
now being re-interpreted by the courts to allow for more flexibility in developing plug
compatible solutions (that may have some common design structure but no common code), the
software marketplace is poised to better be served by competitive COTS (Commercial Off-The-
Shelf) offerings for reuse.

On the technical side, research in process programming, persistent object bases, and knowledge
representation and manipulation show potential for facilitating the creation of fertile reuse
environments. The success of ARPA's Domain-Specific Software Architecture program also
provides valuable credibility to reuse in general.

Myth #2: Special Tools are Needed for Software Reuse

Integrated CASE tools, when they get here, have the potential to enhance software reuse. While
they are not necessary for reuse, they do go a long ways toward making reuse fun. They will
facilitate the traceability of requirements to design and code, along with the other artifacts
associated with software development. Reusable software can be thought of as a CASE tool in
itself in that reusable software components are just another tool that should be leveraged in
solving problems.

Myth #3: Reusing Code Results in Huge Increases in Productivity

There has been a lack of good empirical data related to reuse success stories. There really should
be more data out in the literature, but there isn't. While it is true that in some instances, reuse has
been shown to result in a 20 to 1 reduction in effort for "certain" stages in the development life
cycle, this should be placed in perspective with the "cost" of reuse.

There are three costs associated with reuse: the cost of making something reusable, the cost of
reusing it, and the cost of defining and implementing a reuse process. Focusing on the cost of
making software reusable, a conservative breakdown is a follows:

25% for additional generalization

15% for additional documentation

10% for additional testing

5% for library support and maintenance
______________________________________
60% additional cost of making something reusable

The subtle/sad thing is, reusability is quite subjective. Who can say that spending x% on
documentation will make it y% more reusable, or an additional z% spent generalizing will make
it q% more reusable1 Obviously, you don't just "spend the money", you focus it on making
certain attributes of the software "better".

Myth #4: Artificial Intelligence Will Solve the Reuse Problem

I have always been skeptical of "imitation intelligence." Recently, through my involvement in
the ARPA DSSA community, I have become convinced that software reuse is the common
ground where AI and software engineering will meet. It is becoming more and more apparent
that one needs to reuse more than just code to gain increased benefits from reuse. AI, with its
knowledge acquisition and representation experience, has a lot to offer to support this kind of
reuse. In fact, machine learning and knowledge acquisition closely resemble application
generators and domain analysis -- both fundamental to software reuse.

Myth #5: The Japanese Have Solved the Reuse Problem

The Japanese continue to do good things by taking an evolutionary rather than revolutionary
approach. They have recognized the non-technical inhibitors to software reuse and have invested
in creating the assets and processes to support reuse. As I have previously stated "Before you can
reuse software, you need software to reuse." They have addressed this issue head on, though they
haven't declared victory yet.

Myth #6: Ada has Solved the Reuse Problem

Ada has not, nor will not go away. Ada9X has made claims to have increased support for
reusability in the form of an anemic inheritance mechanism and object types (but it still lends
itself for improvement as well as abuse). As far as a language that promotes reuse goes, C++, as
baroque as it is, has almost become the defacto standard, but again, it is missing some
parameterization capabilities that would enhance its applicability.

Myth #7: Designing Software from Reusable Parts is like Designing Hardware using
Integrated Circuits

I have wavered on the position I took on this point five years ago, as the analogy of component-
based software design and component-based hardware design is conveniently seductive. (Yes
Brad Cox, I hate to admit you may be right with your software-IC analogy.) The big "if' that
makes me want to agree with the analogy is "if software interfaces were defined as crisply as
hardware interfaces" then I would believe the myth is true, especially in light of all the object-
oriented religious fervor that has been so popular of late. But of course, there are no catalogs of
components, outside of user interface widgets. The reason may still lay in the immaturity of the
science, or in that we do not understand the complexity of integration. Said another way, we
don't understand the types of glue/solder that are needed to connect the components together
with, nor do we have standard bus protocols to let us hook up larger components.

Myth #8: Reused Software is the Same as Reusable software

This point needs no discussion. With several reuse standards for "designing software for reuse"
available, it is testimony that reusability, like quality, is an attribute of software that must be
planned for. It is refreshing to see that the government is finally recognizing the difference
between "unplanned/opportunistic" reuse, which it (and others in industry call "salvaging") and
"planned" reuse.

Myth #9: Software Reuse Will Just Happen

In five years time, reuse has been given a lot of press, but it really has not blossomed. I am
encouraged by the DoD initiatives (e.g., STARS, ARPA's DSSA, and tile DISA CIM effort). I
am also pleased by the progress HP and IBM have made at institutionalizing software reuse as
part of tile Corporate programming strategy.

The bottom line is that software reuse is maturing. It has learned to crawl and in the next 5 years,
may even walk upright without dragging its knuckles.

References

[Tracz87h] W.J. Tracz, Software Reuse Myths. ACM Software Engineering Notes, volume 13,
Number l, January, 1988, Pages 17-21.



Reuse Facts and Myths

Michael Wasmund
IBM Geffi1any, Schoenaicher Str. 220, D-71032 Boeblingen

The following is the view of a practitioner rather than of a scientist.

Myth #1: OO eats up Reuse

Fact #1: OO does not automate Reuse, both can complement each other.

Non-technical, i.e., management circles are increasingly frustrated by the slow progress of reuse
in terms of realized .Return of Investment. Object-oriented technologies are often viewed as
having reuse 'built-in', thereby enabling the introduction of two technologies at once with
reduced effort. This view is supported by attributes of OO technology, namely inheritance and
polymorphism, which provide adaptability of available objects to diverse environments.
Reuse is a software engineering discipline rather than a technology. It can be applied to any type
of software assets; be it class libraries or 3rd generation software. OOT is in no way a
replacement for reuse, OOT does not automatically yield high reuse rates, but OOT is an
enabling platform for high degrees of reuse if explicitly planned for and appropriate actions
taken. Ignoring this experience leads to generation of software which is object-oriented but not
reusable beyond a very limited scope.

Myth #2: Incentives are key to Reuse Success.

Fact #2: Incentives create awareness, are cheap but don't change much.

Major companies established incentive programs to stimulate reuse and consider this helpful
particular in the beginning stage. However, massive progress caused by incentives is seldom
reported. To my opinion, the reasons are: First, traditionally organized development teams are
'booked' to an extent, which doesn't provide any extra space for efforts to build reusable
software, even if encouraged. Second, when accepting an award, individuals, who displayed the
desired behavior even before establishment of the incentive program, mostly win. Third,
incentives are an external motivation, which can yield temporary compliance to desired
behavior, whereas intrinsic permanent motivation is not generated. An alternative way is the
establishment of quantitative targets for reuse. At IBM's system software development site in
Boeblingen, Germany, we did test both approaches: Mandating reuse targets significantly raised
the level of practiced reuse in general, whereas incentives helped to create awareness, didn't cost
much, and didn't change much.

Myth #3: Reuse is for free.

Fact #3: Reuse is a mid-tern investment impacting the entire software development process. It
must be based on a product strategy which spans several releases or a family of products.
A frequently practiced initial approach to reuse is the traditional common code concept which
benefits the single project. I consider this concept helpful, but do not expect significant
improvements by this for the future.

A more advanced approach is the transformation of traditional incremental product development
into a growing collection of interoperable software assets, forming a product building kit. The kit
provides the enterprise with essential flexibility when responding to future market demands. To
obtain this flexibility, significant investment must be made at an early stage, spanning all phases
of the development cycle, from domain analysis to maintenance. Short-sighted investments in
reuse are cheaper but return nothing.