SOFTWARE REUSE

Software Reuse
Software reuse is a productivity technique
attempted by many development organi-
zations, with mixed success. In analyzing

Antipatterns
reuse failures, a number of antipatterns
emerge. Antipatterns are obvious, but wrong,
solutions to recurring problems. This article
outlines a number of reuse patterns that have

Revisited
been observed within the software industry.

KEY WORDS
antipattern, asset, component, library, pat-
tern, repository, reuse
JOHN LONG

Editors Note: Although this article was originally published in

2001, many of the experiences associated with the practice of
software reuse continue to resonate today. In addition to leverag-
ing open source libraries, many organizations have policies or
informal practices supporting code sharing and reuse. We are
honored that the author has also provided a retrospective on this
article, sharing his additional perspectives and insights on this
topic from the nearly two decades since this originally appeared
in print. The new commentary appears at the end of this article.

PREFACE
When I originally wrote this article in 2001, I had been working
in the reuse world for some time and wanted to share some of my
experiences about reuse that ran counter to the obvious. I wish I
would have continued to write along these lines, because I prob-
ably could have found tremendous success writing books about
antipatterns, including father antipatterns, husband anti
patterns, and getting rid of wasps using fireworks antipatterns.
As the software industry has embraced agile development more
and more, there would seem to be ample reasons embracing sys-
tematic reuse as well, but reuse will always require planning. It is
unfortunate that agile development is more focused on timeliness
than quality. However, if the software product is successful, there
may yet be time afterward for harvesting and systematic reuse.
Since writing the article, my career has moved me into archi-
tectures and process workflows. Concerning the latter, there is
typically not a problem with organizing a process library (Field
of Dreams antipattern) because the processes typically fit within
some business process hierarchy or enterprise framework. Nor
is there typically a problem with overselling the value of process
reuse (Cost-Cutter antipattern). However, there are often problems
with quality of the workflows (Garbage Dump antipattern), which
is why I wrote Process Modeling Style in 2014.
I hope these few words of wisdom from the past will help
inspire the next generation of reusers.

4 SQP VOL. 19, NO. 4/ 2017, ASQ

 Software Reuse AntipatternsRevisited
INTRODUCTION
Software reuse is nearly as old as the software profession
itself. I can remember my days in college working with
keypunch cards. If I needed to create a new program,
I often reused individual keypunch cards in my new
program. This was often necessary, since the first few
cards were in a complex language that allowed my program
to be readable by the mainframe computer I was using.
(Students from the old keypunch days will remember job
control language, or JCL.) These cards contained ones
name, student ID, and a variety of codes. Students never
really understood what was on these cards, but they reused
them because their programs did not run without them.
That was reuse in the small. In other words, I was
just getting some small tactical benefit out of reusing
bits and pieces to make my next program.
Years later, as a graduate teaching assistant, I taught an
introductory computer science class to business majors.
Their first assignment was a simple program that used a
single loop and some print statements. When my students
turned in their assignments, they all looked pretty similar.
After all, it was a very simple assignment. However, I had
to give a failing grade to one student who had obviously
reused the entire set of keypunch cards of another
student. He had copied the single comment line used by the
other student, as well as the control cards at the beginning,
which contained the other students name. That was not
only reuse in the small but reuse in the boneheaded.
Today, of course, programmers still practice reuse in
the small. Programmers create modules and objects that
they may hand over to another programmer down the
hall to use in creating their next system. As valuable as
this might be to the typical programmer, the benefits of
reuse in the small pales in comparison to the prospect
of reuse in the large, also called systematic reuse.
One of the first jobs I ever had was with a large defense
contractor. One of the companys specialties was combat
simulations for the U.S. Department of Defense. The
company primarily built air-to-air combat simulations
involving aircraft, but it reused these simulators to build
ground combat simulations involving infantry and tanks.
This was reuse in the large. Years later, I was talking
to an individual who had been on the receiving end of
one of these simulations. He said the ground combat
simulation was a good one, but he noticed that the tanks
could somehow mysteriously fly across lakes and other
bodies of water. Obviously, this was not only reuse in
the large, but also reuse in the absurd.
Systematic reuse involves the repeated use of software
to build new systems or extend existing systems, resulting
in some significant benefit. These benefits may include
improved quality, reduced cost, improved schedules,
or enhanced maintainability. To carry out systematic
reuse, software organizations must undergo significant
organizational, process, and compensation changes.
Otherwise, reuse will remain just a dream.
WHAT ARE REUSE
ANTIPATTERNS?
Many different software organizations have attempted
systematic reuse in the past, with often disappointing
results. This is because they attempted to solve the
problem with what I call reuse antipatterns.
Before I can define the term antipattern, I need to
define what I mean by pattern. A pattern is an answer
to a significant, recurring problem. Patterns are different
from good ideas (Coplien and Harrison 2005) because:
A pattern solves a problem. It is not just an
abstract or theoretical approach to a problem.
A pattern has a proven track record. It has
been demonstrated to solve a problem.
The solution is not obvious. Many problem-
solving techniques (such as software design
paradigms or methods) try to derive solutions
from first principles. The best patterns
generate a solution to a problem indirectly
a necessary approach for the most difficult
problems of design.
A pattern describes a relationship. Patterns
do not just describe modules, but describe
deeper system structures and mechanisms.
The pattern has a significant human
component.
An antipattern is similar to a pattern except it is an
obvious but wrong solution to a problem. Antipatterns
have been tried over and over again with the same
result: failure. Nevertheless, these antipatterns will be
tried again by someone simply because they appear to
be the right solution.
Antipatterns were first introduced by Michael Akroyd
in a presentation at the 1996 Object World West confer-
ence (Akroyd 1996). It was created as a reaction to the
pattern literature that had been floating around since the
early 1990s. By 2001, antipatterns had been the subject
www.asq.org 5
 Software Reuse AntipatternsRevisited
of a number of collaboratively authored books (Brown et
al. 1998; Brown, McCormick, and Thomas 1999; Brown,
McCormick, and Thomas 2000).
Following is a list of many of the reuse antipatterns
I am aware of, but first I need to define a few terms
related to reuse:
Component: A source code or executable
that is designed for reuse and manipulable via
aninterface.
Asset: Any artifact that may be reusable. An
asset might include source code, executables,
designs, requirements, test cases, test data,
templates, or other development work that is
storable in electronic files. Components are
just one type of asset.
Systematic reuse should focus on reuse of specific
types of assets, and component reuse is just one type
of reuse. It should be noted that components are source
code or executable assets specifically created for reuse.
I will use these terms in the following antipattern
descriptions. For those in the patterns community,
these antipatterns are just representative scenarios, not
formal antipattern descriptions. The antipatterns are:
Field of Dreams
Garbage Dump
Abracadabra
High Noon
Used Car Fiasco
Hunter-Gatherer
One Size Fits All
Domain Analysis Paralysis
Object Explosion
Of Course its Reusable!
The Cost-Cutter
Each antipattern will be described in two ways. First,
there will be a textual overview of the antipattern, which
will primarily be of interest to the general audience.
Second, there will be a more formal antipattern defini-
tion, which will use the template in Table 1.
It should also be noted that Scott Ambler first created a
set of antipatterns for reuse in the February 2000 issue of
Software Development magazine (Ambler 2000). However,
his article did not formally define the antipatterns. In addi-
tion, his antipatterns were somewhat short. This article
addresses many of the same issues but provides more
description and rigor to the definition of the antipatterns.
6 SQP VOL. 19, NO. 4/ 2017, ASQ
TABLE 1 Format for antipattern
definitions
Antipattern Name
Reuse-related
motivation or problem
it is trying to solve
How it is applied
Actual results
and unintended
consequences
Primary fallacies
2017, ASQ
Related antipatterns
Key words
The problem of reuse antipatterns begs for a resolu-
tion to the antipatterns, which are simply called reuse
patterns. Amblers article identifies a number of reuse
patterns, but again in an abbreviated form. The end of
this article identifies a number of reuse patterns as well,
but does not describe them in depth due to the length
of the material.
ANTIPATTERN DEFINITIONS
Field of Dreams
In a hit film years ago, Kevin Costner is a farmer in the
Midwest, wondering how he will keep his struggling
farm going. A mysterious voice whispers, If you build
it, they will come. Somehow, he realizes he is supposed
to build a baseball diamond in the middle of his corn
field. Reluctantly, he obeys. By the end of the movie, a
long line of cars is waiting to get in to see baseball games
take place on his diamond.
One of the most oft-repeated mistakes experienced
by any organization starting a reuse program is to think
that all it needs to do is create a reuse library, a place to
put its reusable assets. This is usually the result of grass-
roots thinking. If we just create a repository someplace
where people can find our little code snippets, they will
be beating down the door to use whats in there, so the
thought process goes. In other words, If you build a
reuse library, they will come.
A few hot-shot programmers contribute some of the
code they have used successfully. Others volunteer to
run the library on their own. They take the code, put it
into zip files, and place it into a library on the file system.
Several internal messages are broadcast, proclaiming a
reuse repository is about to be initiated.
 Software Reuse AntipatternsRevisited

The day comes for the repository to be open to the requirements, presentations, templateseverything!
programming community. The librarian waitsand Weve set our sights too low about this reuse thing. From
waits. Finally, the phone rings. What was the location now on, everyone should put everything into our reuse
of that library again? someone asks. repository. Its a mandatory part of your job. Just find
Over the next few months, the librarian examines the the right place to put your stuff, and place it in there.
access logs and realizes that very little of the code has Programmers, architects, testers, and others began
actually been downloaded by anyone. One individual putting everything they created into their repository.
has contributed some code, but it turned out to be quite At first, it was nice being able to browse around at what
buggy, so it was discarded. others in the department had been doing. Artifacts from
The group decides that they have not really publicized one project were occasionally useful in the next project.
the repository very well, so they send out more messages, Unfortunately, it did not take long before the reposi-
brief managers, and post signs. Within the next few tory became too large and too jumbled for anyone to
months, a few more inquiries are made, and a little more really use. Workers often had to ask around about the
code is downloaded, but again the results are disappoint- location of a file, which only occasionally resulted in
ing. What did we do wrong? they ask themselves in a actually finding the file. Many times, it took so long to
department meeting. Why wont anyone use our library? find something that the individual just gave up.
The repository falls into disuse and is one day removed I have witnessed this same problem in a major
to provide more storage space for the department. Moral: corporation that had a very large amount of contributed
Creating a place for reusable assets, while laudable, does software. The software was organized only by title. It
not bring about systematic reuse (see Table 2). took a significant amount of time for potential reusers
to find what they were looking for. Searches often led
TABLE 2 Field of dreams to dead ends. In the end, the company gave up on the
whole idea.
Antipattern Name Field of Dreams The idea for the repository was a good one, but the
Reuse-related A need to store reusable assets so repository simply contained too many documents for
motivation or problem others could reuse the assets
it is trying to solve
most individuals to find what they were looking for. Moral:
How it is applied A reuse repository is created and
If companies try to get anything and everything for reuse,
assets are stored in it, but that they will end up having nothing to reuse (see Table 3).
is all.
Actual results Only a few people end up using TABLE 3 Garbage dump
and unintended the assets in the repository. There
consequences is little business justification Antipattern Name Garbage Dump
to continue to support the
Reuse-related Developers within the organization
repository.
motivation or problem are always creating new software.
Primary fallacies Potential reusers assumed to it is trying to solve There must be a way to collect it
already be enabled to reuse. all and make it available for reuse.
This involves understanding
How it is applied A reuse repository is created. A
the value of reuse, trust in the
large number of assets are stored
reusable assets and their support,
in the repository, of varying quality,
knowledge of what assets are
overlapping in functionality, and in
available, and other aspects.
a haphazard manner.
2017, ASQ

Related antipatterns Garbage Dump

Actual results After some initial use, there
Key words Repository and unintended is great reluctance to use the
consequences repository.
Primary fallacies Assuming the quality of the
Garbage Dump reusable asset does not matter;
not providing sufficient capability
The next common fallacy is related to the previous to browse, search, and find assets
one. In this scenario, the role of the reuse repository is of interest amid a large number
of assets
greatly expanded. You know, there are lots of things
2017, ASQ

Related antipatterns Field of Dreams

that can be reused, beams the department manager.
Its not just code. We can reuse test cases, designs, Key words Repository, catalog

www.asq.org 7
 Software Reuse AntipatternsRevisited

Abracadabra No, Jack. We can still call it reusable. Its gotta be

The process of creating highly reusable assets is so very
different from the process of traditional software develop-
ment that many high-level managers often just throw
their hands up in confusion and declare that the results
of the next software development effort will be reusable.
Abracadabra! Presto! Change-o! Reuse will happen!
This may sound ludicrous, but this is sometimes the
intention of executives not well-versed in systematic reuse.
Consider an executive named Steve who announced
to his organization that they were now going to create
reusable components for other groups to reuse. All
of Steves managers agreed that this was a worthwhile
mission and agreed to get started implementing the
necessary changes. A few months later, Steve is visited
by Jack, one of his managers, who says, Steve, you gave
my department the objective of creating components for
the Yangtze.com project, right?
Yeah, Jack pauses, wondering whats next.
Well, you only gave us two months to create these
components, Steve continues. These are supposed to
be reusable components. Components that other groups
can reuse besides this project. We dont have time to
make these reusable. We barely have time to get these
out the door as it is.
I understand, Steve, but were running on internet
time here. We have to get these components out ASAP,
replies Jack.
Well, can we at least drop the reusability require-
ment? asks Steve.
TABLE 4 Abracadabra
Antipattern Name Abracadabra
Reuse-related A high-level manager feels
motivation or problem frustration that no one will reuse
it is trying to solve the software of other groups.
How it is applied The organization does not have
time for reuse now. Employees
are told to go ahead and develop
software and that in the future
lots of groups will be reusing the
software because of how good it is.
Actual results There is little actual reuse due
and unintended to inadequately enabling groups
consequences toreuse.
Primary fallacies No actual focus on reusejust talk;
executive leadership is also missing.
2017, ASQ
reusable to somebody. Just meet your deadline even if
we have to dump some functionality. Jack begins to
walk out the door and turns. Steve, will we ever get to
make these components really reusable?
Someday, Jack. Someday. After weve got a few
releases out, maybe we can focus on reuse. The result
was that the development teams got very little benefit
from reusing the software. They did not get much
reuse, because they did not make that an explicit goal.
If a company does not plan for reuse, it will not get much
reuse. Moral: If a company does not focus on reuse, it
just will not happen (see Table 4).
High Noon
The major problem with the Abracadabra antipattern is
that some managers just assume reuse will happen if they
simply state that reuse is going to happen. Of course,
not all managers are so naive. Some managers actually
go that important step and tell their subordinates to
reuse each others code. This type of manager makes
the assumption that merely telling others to produce
reusable code will result in actually doing so.
The scenario often goes like this. Executive Ed brings
his managers into a strategy session. During that time,
he outlines that he wants to get the benefits of software
reuse. To do this, all of his managers must reuse each
others code. They all leave the session later, determined
to make the reuse work.
Bob, a manager with the FooBar project, is eager to get
his project started with some form of reuse. So, he calls
around to the other managers. Do you have anything I
might be able to reuse? he asks. No, they tell him, but
theyre all ready to reuse anything he might come up with.
As time goes on, Bob realizes that he just has to create
his application from scratch. He considers making his
code available to others, but it is too specialized for them
to use at the present, he does not have the resources to
make it more generic, and he does not want anyone to
ask him to make changes to it. Doing anything to further
its reuse would take away resources from his project,
which is already under time and resource pressures.
Although he might help someone else, he knows that
he is evaluated on how well he finishes the project hes
on, not on how much he helped someone elses project.
Weeks later, when Mary, another project manager, asks

Related antipatterns High Noon

Bob if he has anything she might be able to reuse, he
Key words Management
pauses, but answers no. He has nothing he can offer.

8 SQP VOL. 19, NO. 4/ 2017, ASQ

 Software Reuse AntipatternsRevisited

The whole scenario is reminiscent of the old movie software. He spends the time to go into the code in depth
High Noon in which gunfighters square off against and fix a few more problems that he sees.
each other in the main street, waiting to see who will Unfortunately, the problems keep cropping up. Chen
draw a gun first and fire. In the same way, these project is faced with the decision of either rewriting the code
managers are all staring each other down, waiting for himself, or continuing to try and fix the reusable
someone else to go first and create something reusable. software. He has already invested so much time into the
They are perfectly willing to try to reuse what someone software that it seems a shame to throw it away, but with
else creates, but none of them are willing to actually all the time it took to understand the code, test it, and
create anything reusable. They know it will only draw debug it, he probably could have done it from scratch
resources away from what they are already doing, and himselfand with better results. Chen tells Mary that
it wont benefit them. Moral: Reusable software will they should not try to reuse anything they got from Bobs
usually not be created unless there is a dedicated team team. Its not a good use of their time and resources.
(see Table 5). If reusable software is not of high quality, then it is
like buying a used car from a previous owner. People
TABLE 5 High noon never really know what they are going to get. They might
get a good deal, but the seller might not be telling them
Antipattern Name High Noon what is really wrong with the car. Or, the seller might
Reuse-related No one will either reuse the assets not really be aware of problems in the car. By going to
motivation or problem of other groups or make reusable
a dealer who gives warranties and other assurances,
it is trying to solve assets for other groups.
people can be much more sure that the used car will
How it is applied Management mandates that
reusable assets will be created not break after they buy it.
and reused, but no support is If the dealer ends up selling a bad car, the buyer
provided to carry it out. probably wont ever buy another car from that dealer.
Actual results Each group declares it is ready to Moral: If ones assets are not of product quality, reusers
and unintended reuse, but no one actually does
consequences so. They blame each other for not
typically will not come back (see Table 6).
producing the right assets, not
reusing something they should be
reusing, and so on. TABLE 6 Used car fiasco
Primary fallacies Not providing positive incentives,
processes, and support for reuse Antipattern Name Used Car Fiasco
Reuse-related One group has software that
2017, ASQ

Related antipatterns Abracadabra

motivation or problem another group believes it
Key words Incentives, process, management it is trying to solve couldreuse.
How it is applied The software is made available
as-is from the originating group
Used Car Fiasco without any determination of how
reusable it is.
Lets return to the previous story and consider a differ- Actual results The reusing group finds that the
ent outcome. Bob has conscience pangs and decides to and unintended software has numerous bugs
make some of his software available for reuse after all. consequences that require significant effort to
fix. The originating group is not
He calls Mary back and tells her about a few programs
interested in making bug fixes,
that she might be able to do something with. He promises so the reusing group has to do it.
to have one of his developers call her technical lead to However, the software continues
arrange for a transfer. to have bugs, so the reusing
group just abandons the software
The transfer takes place, and Marys technical lead, and starts from scratch.
Chen, finds some useful conversion software to reuse. Primary fallacies Not testing the software and
He plugs it into his application and starts testing. It certifying its reusability rating
seems to work fairly well with the few tests he tries, before making it available
forreuse
although he does have to make a few bug fixes. Weeks
2017, ASQ

Related antipatterns None

later, during integration testing, Chen finds that there are
some inconsistent results coming from the conversion Key words Testing, certification

www.asq.org 9
 Software Reuse AntipatternsRevisited
Hunter-Gatherer
Many primitive cultures consisted of what anthropolo-
gists call hunter-gatherers. These hardy individuals
lived completely off what the land provided them. This
might include hunting animals and/or gathering whatever
berries or wild fruits and vegetables could be found. If
conditions got such that they could no longer find what
they needed, they moved on.
The hunter-gatherer evokes a vision of the noble sav-
age, roaming across the forest and plain, searching for
his daily provision. Needless to say, land was not really
settled by these types of people. It wasnt until farming
and trade came along that a land could permanently
be populated by a group of people. Harvesting in the
wild may have been adequate for primitive cultures,
but organized and planned harvesting (that is, farming)
yielded much more powerful results.
This is similar to what happens in an unorganized
reuse effort (also called opportunistic reuse). To reuse
software, a project team must sift through a lot of software,
looking for those few good parcels of code, bypassing
lots of other stuff that just doesnt have value. It takes
quite a bit of time, since a code harvester must try to
understand the software. Often, there are inadequate or
missing comments, requirements, designs, documenta-
tion, or test cases. The harvesters gather everything that
seems to be valuable and then try to reassemble it into
a reusable component.
I once worked for a telecommunications company that
spent a lot of effort creating configurators for its switching
systems. It seems that telephony switches come with lots
of options, and there was a great need for applications
that could easily step a customer through the different
options and then lay out the different parts needed by
the configuration team and the pricing of the parts for
the sales team. Unfortunately, the company was always
creating new configurators. Whenever one product line
came up with a configurator, they expected the other
product lines to reuse their configurators, but it never
happened. The company always just created another
configurator for the next product line.
As an individual charged with promoting reuse, I
noticed a particularly good configurator that had been
developed for one of the smaller product lines. In a
meeting, I expressed a desire to harvest the configurator
and make it reusable for other product lines. I figured it
was time for someone to put an end to reinventing the
configurator over and over.
10 SQP VOL. 19, NO. 4/ 2017, ASQ
Afterwards, a number of people who were familiar
with that configurator came to me, with desperate looks
on their faces, trying to persuade me not to reuse the
configurator. It is really, really bad code, I was told by
one individual. Really bad stuff. Youll have to rewrite at
least half of it. If you want to make it reusable, its best to
start over. Needless to say, I gave up that project. Only
software that is of good quality may yield good results
when harvested for reusable components.
In the same way, a farmer can yield a bountiful harvest
if he prepares his field, plants the seeds in an orderly
way, keeps out the weeds and bugs, and harvests at the
right time. Organizations that attempt to reuse without
changes in organization, quality, and planning often
end up as groups of hunter-gatherers. Moral: Harvesting
reusable software only yields good results if it is planned
for (see Table 7).
TABLE 7 Hunter-Gatherer
Antipattern Name Hunter-Gatherer
Reuse-related A project team wants to extract
motivation or problem software from one application to
it is trying to solve use in a new development effort.
How it is applied A small team is put together
to extract the software from
its existing application. It is
assumed to be a short-term
task. After extraction, the team
must resolve missing identifiers,
fix functionality that no longer
works, introduce a greater level
of generalization, and port the
code to a new platform. This takes
longer than expected.
Actual results The cost of the harvesting effort
and unintended was underestimated. Tasks
consequences that had dependencies on the
harvested software got behind
in their schedule and the project
slipped major milestones.
Primary fallacies Underestimating the cost of
reusing unharvested software. All
reuse has a cost.
2017, ASQ
Related antipatterns Used Car Fiasco
Key words Harvesting, extraction, cost
Of Course its Reusable
Related to the Hunter-Gatherer antipattern is the Of
Course its Reusable antipattern. In their zeal to uncover
reusable assets, harvesting teams often find a consider-
able amount of software that works well within its context
 Software Reuse AntipatternsRevisited

and appears, at first look, to be reusable as-is. This is
the gem or mother lode that harvesters want to find.
The idea is that, since the software worked so well in
another development project, then it must be useful in
plenty of other projects, too. This is one of the main
driving forces behind the desire to reuse.
Unfortunately, that concept is a bit naive. Most soft-
ware that was developed for a specific application must
undergo some change to make it reusable. That typically
involves increased and enhanced documentation and
self-descriptiveness, more abstraction and generality,
adherence to standards, and testing in wider contexts.
It may also involve some redesign and recoding.
Once in a while, software is found that is reusable in
a wide variety of contexts as-is. However, these tend to
be smaller in size. See the Object Explosion antipattern
for problems related to small granularity. Moral: Dont
confuse a reusable gem for an unpolished lump of
coal (see Table 8).
TABLE 8 Of course its reusable!
Antipattern Name Of Course its Reusable!
Reuse-related A software asset that has
motivation or problem significant functionality is reused
it is trying to solve as-is.
How it is applied The software is given to a group
to reuse without doing any prep
work to make it fully reusable.
Actual results The team reusing the software
and unintended spends an inordinate amount of
consequences time trying to reuse it. Project
overruns occur.
I tried to install it, but without success. It was about a
half-inch out of sync with the connection points on my
grill. I tried other universal burner replacements, which
were both larger and smaller than my grills stated size,
but none of these universal parts worked. I guess my
grill came from a different universe. After contacting the
grill company, I was able to obtain a part for my specific
grill. It only took me five days of calling to finally get
a service rep at the companys antiquated call center.
Attempts to create a one size fits all product do not
always work. Many times, it turns out to be one size fits
none. Misguided reuse practitioners can fall into this
trap. Once a company decides to spend the resources
to make components reusable, there can sometimes
be a tendency to over-engineer components for reuse.
The result may be that the component is too large or
too generic to be really useful to a development project.
If a component over-abstracts, then it may be very
difficult to understand how it specifically applies to a
situation. In addition, if a component is over-generalized,
it may contain so many levels of inheritance and function
calls that performance, maintainability, and understand-
ability suffer. There is a balance concerning the amount
of reusability in a component. This balance should be
somewhere in the middle between specificity to a single
customer and applicability to any developer at any time.
Moral: Dont make a component too reusable (see Table 9).
TABLE 9 One size fits all
Antipattern Name One Size Fits All

Primary fallacies Assuming that functionality is the
only important aspect of reusing
software. One must also consider
understandability, maturity,
fault tolerance, generality,
portability,etc.
2017, ASQ
Reuse-related A software asset needs to be
motivation or problem made more generic so it can be
it is trying to solve reused by a wider audience.
How it is applied A developer is assigned the task
of making the software asset
more reusable. He or she spends
a significant amount of time

Related antipatterns Hunter-Gatherer

genericizing the software so it can
Key words Harvesting be used by practically any user.
Actual results Advanced developers decide

One Size Fits All and unintended

consequences
against using the software
because it is too cumbersome.
After using my gas grill for a few seasons, the burner They believe they could write their
own analogous software from
needed to be replaced. It was a combination of rust and scratch that would be a lot simpler.
built-up grease gunk, which made it only partially useful. Primary fallacies Adding too many levels of
There were no dealers in my area who carried my brand, abstraction and not constraining
so I looked in the hardware stores for similar parts. the scope of reuse
I found a burner that was the same size as my grill, Related antipatterns None
2017, ASQ

with the label universal burner replacement. It claimed Key words Inheritance, generalization,
abstraction
to work for any brand of grill that was of my grills size.

www.asq.org 11
 Software Reuse AntipatternsRevisited
Domain Analysis Paralysis
Lets return to the corporate setting. One day, Manager
John Knowitall comes into Director George Sludgefactors
office with an excited look on his face. Ive figured it
out, George! The reason we havent been able to get our
reuse program going. Its domain analysis! We should
have been doing domain analysis all along!
George looks over Johns face and pauses. OK, but
whats domain analysis? John then goes into a 15-min-
ute diatribe about scoping the domain, classification
schemes, and more. He assures George that this is the
most important activity to making systematic reuse
work in their enterprise. Georges eyes glaze over after
the first 30 seconds. However, he has always trusted
John to provide good advice. After a few more weeks
and in-depth presentations, George finally approves
Johns domain analysis project. Results are promised
within weeks.
During their first status meeting, John tells George
how difficult it was to get the domain experts together
and keep them interested. When he was able to keep
their interest, the experts provided such an abundance
of information that it was difficult to capture it all. The
domain experts provided a large amount of collateral
material that would take time to synthesize. The experts
themselves were too used to their own documentation
and too busy that they did not participate in helping boil
down the information to just what John needed. It will
take a little more time than I thought, John reports.
After seven months and several more status meetings,
John provides George with a final report, but tells George,
I could have gone on for another seven months, but I
need to get on with the rest of my work. George takes
the report and provides it to a few other colleagues,
which generates a little enthusiasm. However, John never
comes back to George to do a domain analysis again.
Domain analysis has been the subject of a great deal
of confusion over the past decade or so. There are no
real de facto standards for what domain analysis is or
how to go about it. It has been used in object-oriented
analysis and design, knowledge management, and
product engineering. In fact, there is no definitive source
to turn to concerning domain analysis.
This makes domain analysis open game for interpreta-
tion. Software developers who want to do reuse can
convince their managers that they need to do domain
analysis, and when they win approval, they then get to
use it as an excuse for whatever it is they really want to
12 SQP VOL. 19, NO. 4/ 2017, ASQ
do. Consultants also like to convince their customers
on the need for domain analysis because it means lots of
consulting hours. For those who do know what domain
analysis is, the rule of thumb is that it takes six full-time
workers six months to perform domain analysis on a
well-understood domain.
The results of domain analysis are actually useful.
Domain analysis helps provide a common language
and structure for communicating about a domain and
identifies an overall architecture for the domain. It can
help identify which components in the domain have
the most promise for reuse. However, companies can
often get started in systematic reuse without waiting for
domain analysis to complete. In many companies, if one
waits for domain analysis to complete before starting
reuse, the organization will already be in the process of
reorganization. Moral: When starting a reuse program,
do not make it dependent on the completion of domain
analysis (see Table 10).
TABLE 10 Domain analysis paralysis
Antipattern Name Domain Analysis Paralysis
Reuse-related Wanting to know what reusable
motivation or problem software assets should be built
it is trying to solve
How it is applied A domain analysis project is
initiated. No efforts to create
reusable software assets are
allowed until the project is
finished.
Actual results By the time the project has
and unintended finished, enthusiasm has waned for
consequences reuse and the efforts are shelved.
When corporate reorganization
takes place, there is little to show
for the reuse project, and the
project is defunded.
Primary fallacies Not allowing tactical reuse to
prove its worth before investing
in strategic reuse
Related antipatterns None
2017, ASQ
Key words Domain analysis, domain model,
domain architecture
Object Explosion
Many years ago, object technology was touted as the
panacea for a whole range of problems in the software
industry. And, according to the object evangelists, one
of the most important problems it solved was that of
software reuse. The theory was that object-oriented
 Software Reuse AntipatternsRevisited

languages possessed many of the attributes needed
to support software reuse, including encapsulation,
abstraction, loose coupling, and inheritance, among
others. However, it was that last attribute (inheritance)
that actually caused a little too much reuse.
Inheritance allows one object class to inherit func-
tions and attributes from its parent class. This sounds
good, but the difficulty was determining when to stop
creating subclasses. This sometimes caused an explosion
in the number of classes and difficulty in managing
them. However, the most important problem with object
technology was that it often focused reuse efforts at a
very low level. Reusing single classes by themselves often
does not make much sense because of the number of
dependencies on other classes. In one industry standard
e-business product I am familiar with, there are hundreds
of classes that may be reused.
Many times, groups of classes must be reused together
in order to be effective. As developers have recognized
this, classes have been grouped into components.
Component-level reuse makes for a much simpler and
more effective approach to systematic reuse because it
greatly reduces the number of interfaces that must be
dealt with by the reuser. Component-level reuse groups
classes along the lines of use cases or related functional-
ity. Nevertheless, there are still vendors out there that
insist on providing object-level reuse. This is useful
TABLE 11 Object explosion
Antipattern Name Object Explosion
Reuse-related Reuse was not achieved with
motivation or problem traditional programming
it is trying to solve technology, so object technology
is applied.
How it is applied New development is to take place
using object-oriented languages.
Developers can reuse classes.
Actual results Developers cannot reuse a single
and unintended class. They must reuse a large
consequences number of related classes, which
results in the need to reuse an
entire class library. Developers
who do not start their projects by
using the class library are unable
to reuse until they restructure
their software.
Primary fallacies Introducing reuse at a low level
ofgranularity
2017, ASQ
for user interface development, but little else. Moral:
Objects are puny. Real developers reuse components
(see Table 11).
The Cost-Cutter
One of the most obvious reasons managers initiate a
reuse program is to reduce time and costs in developing
software. Typically, the scenario involves a managerI
will call him Timwho does not have the resources to
develop the applications and/or products he is charged
with providing. In a strategic move, Tim brings together
all of his team leads and announces he is going to begin
a program of software reuse in order to reduce costs and
increase time-to-market. He convinces his management
to support this move by pledging to reduce his budget
by 30 percent during the next year.
Over the next several months, Tim oversees the
creation of a reuse library and a number of reusable
components. It is not until the latter part of the year
that projects begin to reuse some of the components.
Initial feedback is favorable. Reusing organizations like
the components, but they do require some modifications
before they can reuse the components. This requires
a considerable amount of additional work to harvest
the modifications, retest, and republish, but the new
components are made available late in the fiscal year.
New projects have not yet had time to reuse the new
versions of the components.
As the fiscal year ends, Tim once again goes to
upper management to discuss the results of the year
and justify next years budget. As he goes through his
presentation, Tim indicates that his organization did
not reduce its budget but actually overran the budget
significantly, having to ask his superior a number of
times for additional funds during the year. However,
with several reusable components in the reuse library
and a number of projects committed to reusing them,
Tim predicted the cost-cutting windfall would happen in
the next fiscal year. All that was necessary was for the
executives to provide the upfront funding to complete
the start-up of the reuse program.
The funding board decided to provide a constant level
of funding for Tims organization with the stipulation
that the reuse program be ended and the compo-
nents provided as-is to the projects that wanted them.
Dejected, Tim went back to his old way of doing things.

Related antipatterns None

Unfortunately, many developers and managers are
Key words Object, class, library, granularity
unaware that the most dramatic benefits from reuse

www.asq.org 13
 Software Reuse AntipatternsRevisited

are often not in the area of reduced costs. Often, the What was surprising is that the study went on to list
greatest benefits are reduction of defects and lower the most important negative factors in software develop-
time-to-market (Poulin 1997). Lower development costs ment productivity. At the top of the list, far above all
do happen, but often not until a few years have passed. other factors, was reuse of poor-quality deliverables.
That is because the initial overhead involved in creating This was the surprising part. This says that reuse, if done
a group focused on systematic reuse are significant in well, can have a very significant boost for productivity.
the first year or so. However, if reuse is done badly, then it can actually hurt
The benefits of reuse are often not seen until a few the development effort. It is critical that any organization
years after starting a reuse program. This is because the seeking to implement systematic reuse do so in a care-
reusable assets must be stable to reap the benefits of reus- ful, well-crafted manner because a badly implemented
ing them. Typically, this does not take place until after approach to reuse will set one much further back than
the asset has been reused a few times, as summarized when he or she started.
by one of Biggerstaffs Reuse Rules of Three: Before To foil the antipatterns described previously, one
you can reap the benefits of reuse, youll need to reuse should use the software reuse patterns. These are:
it at least three times (Tracz 1995). Moral: Systematic 1. Divide and Conquer: Separate the functions
reuse will save money, but not at first (see Table 12). of building, managing, and reusing
components. This shields development
TABLE 12 The cost-cutter organizations from the cost of creating
Antipattern Name The Cost-Cutter
reusable components.
Reuse-related The desire to reduce costs for 2. Publish or Perish: Create a library of assets
motivation or problem a development organization in with multiple, effective catalogs, and push
it is trying to solve the short term by introducing information about assets out to the reuse
systematic reuse
community. This allows reuse organizations
How it is applied The reuse program is sold to
upper-level management as a way to make their assets available in an
to reduce costs in the near term. organized, managed way.
Actual results The start-up costs of starting the 3. Spit and Shine: Make components that
and unintended reuse program eclipse any other
consequences cost savings within the first year
are product quality. By providing product
or so. quality components, the reuse organization
Primary fallacies Assuming that the costs involved will provide a measure of trust that the
with reuse are free or very assets will function as documented.
nearlyso
4. Partner and Build: Build reusable assets by
Related antipatterns None
working with a reuse center. This provides
2017, ASQ

Key words Benefits, costs, quality, time-to-

market, funding a cost-effective way of providing needed
assets in a timely manner by overcoming
the primary objection to creating reusable
RESOLVING THE componentswho pays for it.

ANTIPATTERNS 5. Show Me the Money!: Show the real,

If one were only left with the reuse antipatterns, one
would probably never see anyone implement systematic
software reuse. Many organizations have become so
discouraged about past reuse efforts that the term
reuse has become a negative word. This is a serious
problem. In a study by Jones (2000), the most important
positive factors in software development productivity
were listed. At the top, far above all other factors, was
reuse of high quality deliverables. This is significant,
but not necessarily surprising.
measurable benefits of reuse. Simple,
compelling financial reuse metrics enables
executive sponsorship.
6. Buy-In: Transform the culture from the top
to the bottom. Implementing systematic
reuse typically requires radical changes in a
business environment.
7. Control Thyself: Dont make everything
reusable. Without constraints on what is
made reusable, costs will go out of control.

14 SQP VOL. 19, NO. 4/ 2017, ASQ

 Software Reuse AntipatternsRevisited

8. Plan and Stand: Determine how REFERENCES

reusable assets fit together. Architectural
management is needed to help reduce or
control redundancy in assets.
9. Move Back, Move BackOops!: Make
assets general and abstract, but not too
much. Assets that are too generic are
often difficult to customize.
10. Planning the Garden: If one wants to
harvest, he or she has to plan the garden.
In the same way, if one wants to harvest
reusable assets, upfront planning must
occur to ensure created components will
be valuable to the harvesters.
Akroyd, M. 1996. AntiPatterns: Vaccinations against object misuse.
Object World West, San Francisco, CA.
Ambler, S. 2000. Thinking objectively: Reuse patterns and antipatterns.
Software Development 8, no. 2:60.
Brown, W. J., R. C. Malveau, H. W. McCormick, and T. J. Mowbray. 1998.
AntiPatterns: Refactoring software, architectures, and projects in crisis.
New York, NY: John Wiley & Sons, Inc.
Brown, W. J., H. W. McCormick III, and S. W. Thomas. 1999. AntiPatterns
and patterns in software configuration management. New York, NY: John
Wiley & Sons, Inc.
Brown, W. J., H. W. McCormick, and S. W. Thomas. 2000. Anti-patterns
project management. New York, NY: John Wiley & Sons, Inc.
Coplien, J. O., and N. B. Harrison. 2005. Organizational patterns of agile
software development. Upper Saddle River, NJ: Pearson Prentice Hall.

11. Focus, Pinky, Focus!: Dont try to Jones, C. 2000. Software assessments, benchmarks, and best practices.
Boston, MA: Addison-Wesley Longman Publishing Co., Inc.
reuse small things, like objects, but
medium-grained things, like components. Long, J. 2001. Software reuse antipatterns. ACM SIGSOFT Software
Engineering Notes 26, no. 4:68-76. Available at https://doi.org/10.1145/
(Note: the title of this pattern refers
505482.505492.
to an oft-used phrase in the animated
Poulin, J. S. 1997. Measuring software reuse: Principles, practices and
cartoon Pinky and the Brain in which economic models. Boston, MA: Addison-Wesley.
an intelligent lab rat called The Brain
Tracz, W. 1995. Confessions of a used-program salesman: Lessons learned.
is constantly having to deal with a very ACM 20, no. SI:11-13).
unintelligent lab rat called Pinky.) If the
granularity of assets is too small, reusers BIOGRAPHY
will spend a significant amount of time John Long is a business architect and process architect who has worked
combining assets. If the granularity is across many different industries, including healthcare, crop science,
too large, reusers will spend a significant banking, energy, defense, and software. He has written some profes-
amount of time removing functionality sional books, including Process Modeling Style (Elsevier 2014) and ITIL3
at a Glance. Long holds a masters degree in computer science from
from the assets. This pattern will help
the University of TennesseeKnoxville, and he is still hoping to win the
keep the right balance between combining first Nobel Prize in Dad humor. He can be reached by email at j1long@
assets and reducing asset functionality. mindspring.com.
Each of these patterns foils the
antipatterns shown in the mapping
in Table 13. For example, possible TABLE 13 Antipatterns vs. software reuse patterns
remedies for the Used Car Fiasco anti-
PATTERN
pattern include Divide and Conquer (1),
ANTIPATTERN 1 2 3 4 5 6 7 8 9 10 11
Publish or Perish (2), Spit and Shine (3),
Field of Dreams X X X X
or Planning Your Garden (10). Much
Garbage Dump X X X X X X X
more could be written about these
Abracadabra X X X X
patterns, but that could be the subject
High Noon X X X X X X
of another paper.
Used Car Fiasco X X X X

ACKNOWLEDGMENTS Hunter-Gatherer X X X X X X

This article has been reprinted with permission, One Size Fits All X X X
with additional commentary from the author, from Domain Analysis Paralysis X X
Long 2001. The views in this article are those of Object Explosion X
the author and do not necessarily represent the
2017, ASQ

Of Course its Reusable! X X X X X

views of authors current employer, Blue Cross Blue
The Cost-Cutter X X
Shield NC.

www.asq.org 15