In this column, Bob Glass skewers one of the "old wives' tales" of the software field, the theory-based prediction that software reuse will lead to unbounded improvements in both development productivity and software quality. "It ain't so," he says here. But he certainly wishes that it were.
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?
- 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.
- 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.
- 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!)
- 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.
- 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