Changeability. ... All successful software gets
changed. ... as a software product is found to be
useful, people try it in new cases at the edge of
or beyond the original domain.
Invisibility. Software is invisible and
unvisualizable. (Brooks, pp. 10-12)
Reuse helps reduce the perceived complexity of a
development effort by encapsulating lower level
functionality in predefined, tested and accepted code;
it allows the developer to include additional
flexibility in the initial version of the system so
that it better conforms to human requirements; and it
permits the maintainer to expand and change the
functionality of the system by simply adding new
reusable procedures, functions or objects, or by just
changing the parameters passed to those already
present. Reuse does not directly deal with the problem
of "Invisibility" except that building the system with
a large proportion of previously written code reduces
the need to visualize new aspects of the software. If
one grants that Brooks is correct in his assertion that
these are the essential elements that must be addressed
in enhancing the development process, then it is not
surprising that code reuse has a substantial impact on
the development process. Finally, applying reuse helps
to mitigate the risk inherent in software development
by reducing the number of unknowns (Down, Coleman &
Absolon, 1994, p. 5) in the equation.
Practical Experience
This paper deals with the grassroots
implementation of both white box and black box (Poulin,
p. 2) code reuse on small to medium sized, homogeneous
software projects. The lessons being applied grew out
of a series of projects spanning over seven years in
three different federal agencies. The project that
provided the initial source for reusable code was the
re-hosting of the property management system for the
National Institutes of Health. The Non-Expendable
Control of Property (NECOP) system was a mainframe
COBOL system that was to be moved to a PC based client-
server environment. In the course of developing this
application a need arose for a number of generic
utility programs, procedures and functions both
imbedded in the new system and as separate, stand-alone
programs. Rather than throw these away after the new
NECOP system was turned over to the customer for
operation and maintenance, the author assembled a small
set of the more useful and generic of these programs
into a set of procedure and function code library files
that included both fully compilable code and templates
to support more rapid development of such items as
reports, menus and database index management. Over the
course of the next five years (mid 1990 to mid 1995)
this reusable code library continued to grow and evolve
as it was used by the author and about 20 other
developers (at various times) to develop client-server
systems for the National Heart, Lung and Blood
Institute (NHLBI) and the US Environmental Protection
Agency (EPA), in domains ranging from grants management
to Superfund site risk assessment. Over that time the
host language (Nantuckett Inc.'s (now owned by Computer
Associates) Clipper) continued to evolve from a purely
block structured procedural language into a pseudo-
object oriented, event driven paradigm, yet many of the
reusable procedures and functions continued to prove
useful with minimal changes for any given new release
of the compiler. In fact the vast majority of updates
to this library consisted of changes to take advantage
of new compiler features that enhanced performance or
functionality rather than maintenance to simply regain
current functionality or compilablity with the new
release. When the object orientation began to take
hold some of the template files that had long served as
high level skeletons to jump start development and aid
in rapid prototyping were replace by generic menu,
interface and reporting objects either embedded in the
host language or instantiated by the developer and used
throughout the system, but the overall set of reusable
code proved remarkably durable.
What were the conditions that allowed this set of
flexible and generic functions to be used over such a
long time and in such differing applications? The
first was a common platform, the IBM PC and its clones.
Second, the language selected for implementation
remained the same and continued to evolve in a well
behaved manner. Third, the author made an effort from
the start to identify and exploit opportunities for
reuse in developing code. Fourth, each block of code
was carefully documented with respect to purpose,
function and interface (parameters and return value).
Finally, as the author's design and coding skills
continued to mature, increasingly stringent standards
were brought to bear on these libraries with respect to
internal documentation, code structure, variable scope,
and function parameterization. That is not to say that
these libraries ever underwent an extensive rewrite,
they just evolved with corrections, improvements and
new functions and procedures incorporated as needed.
The impact of this approach to code reuse on the
overall life cycle of the projects was substantial. As
previously stated the initial libraries were assembled
during the final portion of the NECOP project, the
author then moved on to the NHLBI project. The NHLBI
project contract was tailored to provide both software
development and technical support for new and existing
systems. Again, one of the primary activities was the
re-hosting of mainframe systems to the PC client-server
environment. Initially, the reusable library files had
a minimal impact on development as much of the effort
was being expended upon requirements definition based
on an analysis of the existing systems. The first
implementation effort undertaken by the author on this
project made use of the libraries to reduce coding
effort. The impact on the overall schedule was on the
order of a 10% - 15% reduction in coding and testing
time as the author established new look and feel
standards with the client community. As a result of
the code review process in use on this project minor
changes were made to the reusable code libraries and
they were adopted by the other members of the team in
subsequent re-hosting efforts yielding a coding and
testing schedule compression on the order of 35% - 50%
(admittedly the percentages expressed in the is
paragraph are subjective measures as no hard data was
collected at the time). This benefit accrued to the
development process as a result of agreement within the
seven person development team to make an effort to
search the reusable code files before trying to
"reinvent the wheel" and due to the white box reuse of
template files to speed interface, reporting and system
support and maintenance oriented database utility
development. At the same time it was agreed to
continue to try and identify additional functions,
procedures and templates that might be added to this
reusable code set.
It should be noted that this reuse effort
succeeded in an ad hoc software development environment
with little support from specialized tools or an
existing, defined software development process. While
there was general agreement within the team that it
would be a good idea to define requirements and do a
design for a system before proceeding to coding, this
only occasionally happened in actual practice. The
principal tools available to the developers were the
Clipper compiler, various linkers, an ASCII text editor
and the Norton Utilities "File Find" feature (which
supports searching the contents of a set of files,
directories or an entire disk for a specific, user
entered, character string). This allowed the
developers on the NHLBI project to quickly search the
reusable code library files for a string and view the
files contents.
An unexpected impact of this reuse effort was that
one of the major systems developed by the project (the
Grants Award System (GAS) an automated research grant
awarding and tracking system) was flexible enough and
of sufficient quality to be adapted for use in two
other NIH institutes with minimal coding and testing
effort (40 - 60 man hours for each institute). Indeed,
while the initial goal had been to simply develop with
reuse, the team ended up inadvertently developing for
reuse (Poulin, 1997, p. 22).
The point being made is that, while software
process improvement may be worthwhile it does not have
to follow the SIE-CMM or ISO-9000 (Donaldson & Siegel,
1997, pp. 331-333 and 502-506) models to be beneficial.
Within any given software domain applying the most
basic approach to reuse can provide a substantial
payoff. Much of the literature on reuse programs
emphasizes careful repository control, cost tracking
and return on investment calculations to support and
measure reuse. These are laudable practices in a
large, mature software organization, however, they are
not strictly necessary for a reuse program to succeed.
Applying Experience
Software developers, in general, dislike (abhor)
excessive regulation, bureaucracy and paperwork.
Expecting a highly formalized reuse procedure to
succeed in a "cowboy" development environment is overly
optimistic. The characteristics and necessary
components of an effective and successful introductory
software reuse program in an organization where the
idea and/or practice of software process improvement
has not gone vary far are:
- Characteristics:
- Consistency:
The organization's application
domains, platforms and
languages must be consistent
enough over time to make reuse
a worthwhile effort.
- Acceptability:
To succeed a reuse program
must be wholeheartedly
embraced by the development
organization.
- Usability:
The library of reusable code
must be well organized,
thoroughly documented and
easily accessed.
- Reliability:
Components included in the
reuse library must have a
known, high level of quality
and reliability.
- Scalability:
The software reuse program
must be able to grow and adapt
as the organization does both
in terms of application domain
and process formality.
- Components:
- Support:
Support for reuse must take
two forms. First, there needs
to be clear, strong and
continuing support from
management. Second, support in
the form of tools, technology
and resources must be
provided.
- Repository:
To be reused, code must be
collected in a centralized,
secure, commonly accessible
location that is well
organized for finding and
extracting required
components.
- Certification:
To ensure that reusable
components are reliable a
component testing, review and
certification process must be
established (McClure, 1997, p.
248)
- Process:
A defined reuse process must
be created and training
provided in the creation and
use of reusable components,
and in the reuse process and
repository. This should also
define the duties of each
member of the reuse team
(Leach, 1997, p. 15-17) if the
size of the effort warrants.
To be worthwhile reusable code must have a life
expectancy beyond the project it was originally
developed for. Its value to the organization beyond
the current effort is to a large extent determined by
the degree to which the projects the organization
undertakes are of a consistent type, the platforms upon
which the projects are developed are similar, and the
degree to which the computer language used is
consistent with existing code. Change project type and
many of the blocks of code in the organization's
repository are not of value. Change platform and the
entire contents of the repository are at the mercy of
the degree to which the manufactures of both platforms
adhered to open standards. Change computer languages
and the code repository becomes at best an algorithm
repository.
To succeed a reuse process must be accepted by the
members of the organization who have to practice and
support it. To gain acceptance within the organization
reuse must be understood by developers as a way to make
their lives easier and by management as a means to
greater competitive advantage. While everyone agrees
that it is a good idea not to continually reinvent the
wheel, there is somewhat less agreement on how much
effort should be taken to avoid it. Given an overall
low level of process maturity the author's experience
indicates that the senior technical staff is a good
place to start building this acceptance. Experienced
developers are likely to have been practicing an
informal brand of reuse for years and it is reasonable
to assume that they can serve both as a source of
cultural support for the program and as a reservoir of
reusable code from which to build an initial
repository. A small group of these individuals can
assemble a large volume of code, establish coding
standards and provide empirical (if anecdotal) data on
the benefits of reuse to take to management. Once the
reuse process gets underway these individuals can also
serve as mentors to bring other developers up to speed
on the reuse process.
Building initial support for the implementation of
reuse among senior developers is largely a networking
activity, once grassroots support has been built, the
business case must be made to management that
implementing a more formal reuse program will provide a
payoff for the resources expended on it. The key
points to be made to management are that: A) informal
reuse has been practiced throughout the organization
all along; B) a number of top level developers support
the program and that practicing informal reuse has been
a factor in their success; C) while implementing a
reuse plan may require some expenditure of resources,
there has been, historically (site literature and in-
house senior developer experience here), a major pay
off from the success of reuse efforts.
Having established consistency of environment,
support from management, and acceptance among
developers, the next task is to collect, review,
correct, document and establish an initial set of
contents for the repository. This step requires the
first real commitment of resources to the reuse
program. First, developers must do the work of
assembling the repository. Identifying an initial set
of reusable functions, procedures, objects, component
templates and/or applications may be as easy as asking
each developer for the set of these elements they find
most useful, or as difficult as reading legacy system
code for potentially reusable components. Second, the
repository must be given a home in commonly accessible
location with some basic means of securing, searching,
adding, maintaining, and extracting components in the
repository; this implies the acquisition of hardware to
provide storage, retrieval and connectivity and
software to support repository functionality. In some
cases, including the author's previously described
situation, the technologic support for a basic reuse
repository may already be in place. Space was
available on a network drive, a code review process was
in place, the Norton Utilities were available to
support searching and extracting components from the
repository, a regular backup process protected the
repository contents, and the small size of the
development team minimized the need for any additional
resources. In a larger more varied development
environment there is a greater need for software tool
support for searching, configuration management, and
security.
As a usable repository is being setup reusable
components need to be collected, reviewed, corrected
(if required), documented and installed in the
repository. In the case of the NHLBI project the
initial contents of the repository (the author thought
of it more as a function, procedure and template
library at the time) grew out of the review of the
author's function and procedure files from the first
application he developed after moving onto that
project. The level of internal documentation required
to support the reuse effort was more than the author
has seen in many development environments but less than
has been suggested by some (Neufelder, 1993, p. 49); a
typical report output destination selection function
had the following heading which was standard for the
code in the library:
Function REPORT_DEST
*******************************************************************
* Programmer: David R. Mapes
* Language: CLIPPER (Summer '87)
*)Purpose:
*) This function returns the report output destination
*) selected by the user as a descriptive character
*) string. It allows the user to select among four
*) options for output:
*) - Screen display.
*) - Local printer output.
*) - Network printer output.
*) - Print to a local disk file.
*)
*) Parameters:
*) There are four optional parameters that may be used
*) to control access to any of the four options presented
*) to the user. These parameters are passed as logical
*) (True .T. or False .F.) values.
*) - If none are passed then all are assumed true.
*) - If any are passed they are assumed to be
*) what ever value was passed and the
*) remainder are set to false.
*)
*) Usage:
*) - OUTPUT = REPORT_DEST(.T., .T., .F., .T.)
*)
*) Allows output to screen, local
*) printer and disk file but not to
*) network printer.
*)
*) - OUTPUT = REPORT_DEST()
*)
*) Allows access to all 4 options.
*)
*) - Do with REPORT_DEST()
*)
*) Passes the result of REPORT_DEST as
*) parameter to the report program.
*)
*) The return values are:
*) VALUE DESCRIPTION
*) =============== ===================
*) "SCREEN" Send output to the
*) screen.
*)
*) "LOCAL" Send output to the
*) user's local printer.
*)
*) "NETWORK" Send output to the
*) user's network printer.
*)
*) "FILE" Save the output to
*) a file on the user's
*) hard-disk.
*)
*) "ESC" Terminate reporting
*) process.
*)
* Revision History:
* Date By Description
* ========== ================= ====================================
* 12/10/1991 David R. Mapes Initial implementation.
*******************************************************************
...
While the NHLBI project's reuse program succeeded,
it was not formally documented and depended on the
close interaction of the development team to work. So
it lacked the characteristic of scalability and the
reuse program component of a defined process. Because
of this the NHLBI reuse process died out as the author
moved on to the EPA project in 1993 and turnover of
staff, project growth, and the elimination of clipper
for new development at NHLBI placed an insurmountable
burden on the informal process. While the reusable
code lived on for one more major systems implementation
project at EPA, the process that created it was killed
by a lack of documentation, training and clearly
visible evidence of success (beyond the whole cloth
reuse of the GAS system). One must keep in mind that
this was an ad hoc development organization where the
build and fix approach to software development was
often mistaken for a prototyping development life
cycle. However, a simple document explaining the
content, use, roles, measurement and adaptation of the
reuse concept to a changing environment might well have
perpetuated the life of the repository and encouraged
its evolution to support the new development tool.
Simply put, the author had failed to be a successful
"change agent" (LaMarsh, 1995, p. 92-93) in that while
the change was understood, managed and the people were
dealt with, none of these points were handled at a
sufficient level of detail or in a way that would out
live his tenure on the project. A "reuse framework"
(Biggs, 1997) that would last was not esablished.
Conclusion
The bottom up implementation of a code reuse plan
must include the key characteristics: A) consistency
of application domains, platforms and languages; B)
acceptability to the development organization; C)
usability of reusable the code with regard to access;
D) reliability of components; E) scalability of the
software reuse program to grow and change with the
organization. Additionally the reuse program must
include as key components: A) support from management
in terms of resources and technology; B) repository
code collected in a centralized, secure, commonly
accessible location; C) certification ensuring that
reusable components are reliable; D) process defining
documentation of the reuse program must be created and
training provided. Indeed, at NHLBI the author was
solely responsible for maintaining the reuse effort and
with no defined reuse plan spelling out the duties
involved there was no good way of delegating them to
someone else. As Popoff and Brache put it the author
failed "... to leave behind a measurement system and
other parts of the infrastructure necessary for
continuous process improvement." (1994)
The successful implementation of a reuse program
(or any process improvement effort) hinges on
ingraining the change in the organization's culture to
do this the change agent must understand the change:
its impact on the organization; the level of management
sponsorship require; identify the right sponsors and
give them ownership; identify source of resistance in
the target organization. The change must be managed
effectively by communicating, learning, and providing
reward and reinforcement. Deal with the people:
listen, translate massages between change targets and
sponsors, build team strength in support of the change,
track the progress and impact of the change, solve
problems in a timely manor, and delegate the
implementation. (LaMarsh, 1995, p. 92-93)
References
Biggs, Peter. (No date/accessed October 13, 1997).
A case study in small company software reuse.
University of Durham, Durham England.
http://www.dur.ac.uk/~dcs3pjb/paper.html
Brooks, Fredrick P. (April, 1987). COMPUTER (p. 10).
No silver bullet: Essence and accidents of
software engineering.
Donaldson, Scott E., Siegel, Stanley G. (1997).
Cultivating successful software development: A
practitioner's view. Prentice-Hall, Inc. Upper
Saddle River, NJ.
Down, Alex and Coleman, Michael and Absolon, Peter.
(1994). Risk management for software projects.
Mcgraw-Hill Book Company Europe. Maidenhead,
erkshire, England.
LaMarsh, Jeanenne. (1995). Changing the way we
change: Gaining cotrol of major operational
Change. Addison-Wesley Publishing Company.
Reading, MA.
Leach, Ronald F. (1997). Software reuse: Methods,
models and costs. McGraw-Hill. New York.
McClure, Carma. (1997) Software Reuse Techniques:
Adding reuse to the systems development process.
Prentice Hall PTR. Upper Saddle River, NJ.
Neufelder, Ann Marie. (1993). Ensuring software
reliability. Marcel Dekker, Inc. New York, NY.
Popoff, Frank and Brache, Alan P. (June, 1994). Chief
Executive (reprint-no page number). The seven
deadly sins of process improvement.
Poulin, Jeffrey S. (1997). Measuring software reuse:
Principals, practices, and economic models.
Addison-Wesley. Reading, MA.