INTELLIGENT SYSTEMS
Volume IX,
Number 4 December , 2002
Grover and the Silver Bullet
By Arnold Kling
When my kids were younger,
one of my favorite bedtime stories for them was a Sesame Street book called
“Grover’s Resting Places.” The most
adorable scene is where Grover starts rummaging through a toy box looking for
something. After he has strewn most of
the contents of the box all over his room, he pauses and says, “Uh-oh. I had
better be careful, or I will make a mess.”
Software almost always has a
similar phase in the actual development lifecycle. Some time after the system has been in production, the business
needs will tend to evolve in such a way that developers are forced to stretch
it and modify it, piling up ad hoc code.
Then, like Grover, the developers may pause and raise a concern that
they might create a mess—when in fact the mess already is at hand.
Of course, the lifecycle
approach to software development says that you should anticipate business
requirements ahead of time. Software
development managers refer to the process of piling on requirements for
software during the design phase as “scope creep.” As the scope of a project expands, the challenge of completing
the project increases.
However, in reality, most
scope creep occurs after the software already is in production. The only software that does not run into
unanticipated business requirements after implementation is software that never
makes it into production in the first place.
In fact, it is likely that the better a piece of software works for its
original purpose, the more likely it is that users will ask for new features.
The nature of the mess
created by post-implementation scope creep is one of unexpected
dependencies. Once a system has been
modified to handle a situation that was not anticipated in the first place, an
unexpected dependency is likely to creep in.
For example, suppose that
you have a data structure or object called a “mortgage” which includes the
interest rate on the mortgage, to help you track the monthly payments you are
receiving from a borrower. You include
the interest rate in the set of parameters that is used to set up the mortgage.
After this system has been
implemented, someone creates an “adjustable-rate” mortgage. After one year, the
interest rate could be different from the rate that was used to set up the
mortgage. Since nobody wants to break
the existing system and start over, somebody will create a work-around that
enables you to process payments by looking for the current interest rate on an
adjustable-rate mortgage inside a different data structure.
Next, suppose someone has to
enhance the program (say, to allow the mortgage to convert to a biweekly
payment structure from a monthly payment structure). This developer is going to encounter the unexpected dependency
between mortgage type (fixed or adjustable) and which data structure contains
the interest rate on the mortgage. The
developer would have expected the same data structure to contain the current
interest rate, regardless of mortgage type, because that is the way you would
have designed the system in the first place had you known about both types.
It is obvious that
unexpected dependencies are bad. Competent developers know how to avoid
designing them into a system initially.
But they cannot foresee everything.
A former colleague, Chuck
Sheridan, used to say that one of the laws of computing is that “the last
person who worked on this system was an idiot.” This law is a result of post-implementation scope creep.
Post-implementation scope
creep would not be a problem if the business environment encouraged developers
to rewrite systems instead of patching them in response to changing needs. But that is like saying that Grover would
not have trouble finding things if he straightened out his room more
often. In the real world, it does not
happen that way (although perhaps it should).
I get the impression that
very few people understand the Grover’s mess issue with software. For example, one of the most fashionable
buzzwords currently is “e-commerce.”
The Holy Grail du jour is something called an “e-commerce solution.” This will be a single software system that
will enable every business to operate on the Internet.
It is difficult to
understand how anyone could expect e-commerce to come in a box. If all of the business logic of every
company could fit onto one CD, we would not have a very sophisticated economy.
Because businesses are not
all the same, e-business solutions are going to vary. The Grover’s mess problem suggests that the costs of combining
two types of functionality in the same system are higher than the cost of
having the functionality in separate systems.
This implies diseconomies of scope.
For example, Amazon.com has
e-commerce software for buying books. If there were no diseconomies of scope,
this software could be adapted to everything else. In fact, things are not that easy.
You do not need to configure
a book. At most, you specify hardback
or paper. But there are many products,
such as home entertainment systems, that require configuration as part of the
purchase process. The Amazon system
that works very well for one-click ordering of books is not going to be of much
help in selling a home entertainment system.
If Amazon.com tries to enter the home entertainment system market by
modifying its current software, my guess is that it will land in a huge
Grover’s mess.
Priceline.com has e-commerce
software that allows people to name a reservation price for airline seats and
allows airlines to choose whether or not to meet that price. They have tried to do the same thing with
mortgages.
Some differences between the
airline business and the mortgage business that come to mind relatively quickly
include:
1.
Airlines have a problem
with temporary excess capacity (unfilled seats). In mortgage lending, capacity issues are more long-term and
cyclical.
2.
It is relatively easy to
qualify someone for an airline. Once
your credit card is approved and you pass through the metal detector, you are
good to go. In contrast, the
underwriting manuals that are used to classify you as a mortgage borrower can
run to hundreds of pages.
3.
Airline reservations
have relatively limited configuration options.
Mortgages have many options (rate/point combinations, etc.).
It seems reasonable to
predict that to adapt code developed for matching flyers with available airline
seats to the challenge of placing mortgages is going to put Priceline.com
deeply into Grover’s mess. Beam me up if
they find a low-cost solution that achieves market penetration.
Recently, I read an article
by a pundit suggesting that the e-commerce solution is going to come from the
current number one hit on the hype charts, "open source"
software. Short of saying that it can
cure cancer and bring about world peace, this may be the most outrageous claim
that one could possibly make about the “open source” method.
Suppose that I write a
program to play chess. If I make the
source code “open source,” it is reasonable to expect that some other
programmers may make changes that enable it to win more chess games. But it is quite another thing to suggest
that those programmers will find a way to morph my chess program into a program
to play bridge.
With e-commerce, the problem
is the diversity of business needs, leading to Grover’s mess. Open source is not the Silver Bullet for
Grover’s mess.
Frederick Brooks’ original
“No Silver Bullet” article made the point that most of the challenge of
software development is in design. His
assertion is that no software development tool or process will bring about an
order of magnitude improvement in productivity. His argument is that most of these tools and processes are
designed to assist in the implementation of a software design; they do not
alleviate the complexity of the design process itself. Brooks argues that software design is
complex because the objectives we have for software are complex.
The complexity of software
design gives rise to diseconomies of scope.
Any unnecessary increase in the complexity of the business objectives
for software will raise the cost of that software. To say that the same software is going to process orders for
books, airline reservations, beanie baby re-sales, haircuts, and mortgages is
to introduce significant unnecessary complexity in the business objectives.
In conclusion, one of the most important economic facts about software
is that there is no Silver Bullet for Grover’s mess. There is no low-cost way to expand the scope of software beyond
its original purpose. Because many
businesses depend on software, this in turn means that there is no low-cost way
to expand the scope of a business. The
diseconomies of scope are huge, and yet they are nearly always
under-estimated—or even ignored completely—in business strategy. Some possible implications to consider:
·
The
cost of integrating the systems of two corporations that merge could be greater
than the sum of the cost of building the systems in the first place.
·
Opportunities
for "cross-selling" and other synergies among disparate business
lines may prove to be expensive to realize.
·
The
cost of customization of a product or service may be much higher than is
realized.
·
The
cost of patching a system may be relatively higher and the cost of rewriting a
system relatively lower than is realized.
Reprinted
with permission from Arnold Kling. All
rights reserved. Arnold Kling was an
early Internet entrepreneur, and the author of "Under the Radar: Starting
Your Internet Business without Venture Capital." Currently, he teaches high school on a volunteer basis and
maintains two web logs, one at http://www.corante.com/bottomline
and the other at http://arnoldkling.com/gqe/.
“There are only 10 types of people in this world: those who understand binary and those who don't.” -- John Hedtk
“Government scientists tell us that the fastest animal on earth, with a top speed of 120 ft/sec, is a cow that has been dropped out of a helicopter.” -- Dave Barr
“To be conscious that you are ignorant is
a great step to knowledge.”--Benjamin Disraeli