Here's the conventional wisdom: Reuse is about building software from components. The bigger and more generalized the components, the better. At best, software products could be built entirely from such reused components.

The virtues of that kind of thinking are obvious. In addition to dramatically improving software development productivity (since a lot of software no longer would need to be written from scratch), software quality would also be improved, equally dramatically (since software that has been used before has probably already passed numerous reliability and quality hurdles).

That kind of thinking is all well and good, I want to tell you. But it's also wrong-headed! What I want to do here is give you the rationale for my very contrarian position on reuse.

Recently, I received a copy of the proceedings of a software engineering conference whose subject was reuse. Reuse has always intrigued me, starting with my software development days in the late 1950s when the only way to get famous in the software field was to contribute software components to the reuse libraries of that time. Back then, software had no monetary value-everybody was in the Open Source field, whether they wanted to be or not-and so getting famous by selling a lot of software didn't work. And in those days there was no software development literature, so you couldn't even become famous by writing articles like these to share what you knew with others who might (or might not!) care. In an ironic way, it was a purist kind of fame. You became famous by building software, not by selling it or writing about it. So back in those early days I leaped enthusiastically into the field of building reusable software.

But back to the conference proceedings. The more I read, the more depressed I got. The proceedings reeked of the conventional wisdom I mentioned above. There was a lot of advice on how to do a better job of (a) doing, (b) motivating, and (c) managing reuse. There was even the usual collection on how to build better search engines to locate and extract the perfect reusable component for the problem you are working on.

What are the problems with reuse, the ones that make me such a naysayer?
 

1. Reuse "in the small" was a problem solved in the 1950s. We built huge, useful collections of mathematical and data-processing library routines, routines that are commonly used to this day.
2. Reuse "in the large" is and always has been an unsolved problem. In spite of the enthusiasm of the components crowd, finding in a library of components the precise one that will solve your problem at hand is nearly an impossible task.
3. The problem is not that we can't find the perfect component in that library of reusable parts. (That's what those "search engine" folks are trying to solve.) The problem is that the perfect component is simply not there. (And no amount of clever search engines will fix that!)
4. It is tempting but largely unworkable to try to bend imperfect components into perfect ones. Research studies at my favorite home of software engineering research, the NASA-Goddard Software Engineering Laboratory (SEL), have shown that if you have to change more than 15 to 20 percent of a component to make it work in your program, it is more economical to build the component from scratch. And few components meet that 15-to-20 percent threshold.
5. And why is that perfect component never in the component library when you need it? That's where the insight from those conference proceedings comes into play. Paul Bassett of Netron, Canada, said, "Unpredictable variability across systems and over time is why reuse in software engineering is nontrivial." The key word here is "variability." Problems and their solutions in the software world vary all over the map, and having a "close" solution just isn't good enough. There is so much variability across and within domains that the likelihood of someone having previously faced the identical problem you are currently facing is nearly nil.

One person who read my writings on the subject said that I had "set software reuse back by twenty years," to which I replied (in one of those rare, "clever-comeback" moments), "You simply don't realize that it is twenty years behind where you think it is!"

Now that I've thrown cold water on the subject of reuse, let me share one piece of positive reuse data that may astound you (and will certainly make you wonder about which side of this fence I am really on). At the NASA-Goddard SEL, they have found that they can build software consisting of roughly 70 percent reused components. How does the SEL do it? They have a narrow application domain-flight dynamics software-consisting of problems whose solutions over the years are very similar to one another. So if you narrow that variability down sufficiently-by working in a focused problem domain whose fundamental-solution approaches rarely change-you can achieve some pretty potent reuse benefits. But variability is still the key factor.

Let's end this column with a little pop quiz. What's the problem with reuse? (100 points if you answered, "It's the variability in the problems we solve, and in the solutions we create.") Is that problem likely to go away soon? (I hope you'll agree with me when I say, "Only if we can find ways to diminish the problem of variability.")

I am reminded of an old saying: "There is no scientific reason why the bumblebee should be able to fly" (because of its "impossible" weight-to-wingspan ratio). When we confront that conundrum, the sensible among us don't question the practice of bumblebee flying, we question the theory that says it is impossible. It's high time for theory to incorporate studies of practice into its way of moving the field forward. Until we do that, we will be stuck either trying to discourage bumblebees from flying, or criticizing them for ignoring theory.