Grover and the Silver Bullet

"Arguing in My Spare Time" No. 2.13

by Arnold Kling

May not be redistributed commercially without the author's permission.
Index

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