Reuse Abuse

Jeff Alger and Eric Berdahle

Eric,

Hmmm, I know it's here somewhere… aha! here on page 89 of the 1999 Sears catalog:

Abstract Reasoning Class. Through suitable overloading and overriding, can be used to implement any reasoning process in your object-oriented program. One direct slot into which you can insert any information. Three polymorphic methods: Perceive, Cogitate, React. Defaults to no perception, no thinking, no reaction, making it useful as-is for applications such as plug-compatible movie critic replacement. Add $1.95 for next-minute shipping by electronic mail.

C++ version:        $29.95  PN 975337-1
Smalltalk version:  $29.95  PN 975337-2
Lisp version:       ($ 29.95)   ('PN 975337-3)

Sound absurd? Maybe, but the whole subject of software reuse has gotten out of hand, especially in the object-oriented community. Think about all the hype about "Software ICs," those orderable, plug-in class components of the future. Where's the evidence? What reasons are given, other than cult-like faith, for software engineering as we know it suddenly being reduced to choosing whether to buy from K-Mart or Nieman-Marcus? Have you personally ever talked to someone who has routinely achieved large-scale reuse of object-oriented software components? You wouldn't invest your kids' college fund with someone who used equally flimsy arguments for an investment scheme, and you shouldn't put any more faith in snake oil disguised as reusable ones and zeros.

Here's the truth: object-oriented software is highly dependent on its context, and most innovative software is innovative precisely because it subtly changes the context.

The only circumstances in which I have seen widespread reuse have been those in which the context is severely limited. For example, MacApp classes are somewhat reusable because they depend only on the Macintosh operating system, Toolbox, and user interface for context. Smalltalk even carries its context along with it through a portable kernel. This is why it is so easy to find class libraries for graphical user interfaces but not image recognition; data structures but not physical structures; reading and writing files but not parsing complex grammars. In each case, the OO community has rather sensibly gravitated toward the sorts of problems it is collectively well-equipped to solve: problems that are inherently bounded by external factors like operating systems and standards. Sensible, but limited. We cannot extrapolate from that to expect generalized reuse of Employee components from payroll to human resource management to games applications or from a Macintosh graphical user interface to a mainframe database.

For all the talk about how "natural" the process of object-oriented analysis and design is supposed to be, we really make decisions about how to organize object-oriented programs based on artificial considerations: modularity, maintainability, extensibility, and a variety of other Itys. The process is roughly this: decide what behaviors your software needs to exhibit and what data it needs to contain, then distribute them in a modular fashion that would make your old Software Engineering professor proud. Finally, once the design has taken root, start using names that constitute good metaphors so that the design is easier to understand and explain. That Employee class is not the same as its real-world counterpart; we stole the real-world name "Employee" to leverage a basic human perceptual skill, metaphor. Change the context and the whole basis for the Itys has changed. Move most classes from one context to another and the result is poorly structured software.

I expect reusability to grow wherever clever people can identify and clearly articulate narrow contexts and stick to them. This will take time, since it requires observing dozens or hundreds of individual cases before patterns emerge. That is where the object-oriented approach itself came from. However, most truly creative works produced by humankind involve deliberately taking things out of their original context, shuffling them together and then solving some new and outrageous problem with the combination. That's the way my kids play with their toys and I think it's true of truly leading-edge software as well. In fact, one might even hope that we don't take software ICs too seriously, since to do so is to constrain through implied contexts the very creative juices on which the industry thrives.

A final question: who cares? I mean, about generalized software reuse? Programming as a percentage of lifecycle costs is about the size of the period at the end of this sentence and shrinking all the time. Most development costs are in planning, analysis and design, not programming, and most lifecycle costs are in maintenance, not development. If, through reuse, we reduce programming to plug-and-play, it still won't make more than a few percentage points difference in overall software costs. Reuse of analysis and design is, to me, a much more fruitful line of inquiry and one not constrained nearly as much by the peculiar technology we call OOP.

Jeff

Friend Jeff,

I used to think that the software industry learned something from the Oat Bran Craze of the mid-80's, but recently I have come to realize that it is the other way around. Remember oat bran, the fiber health zealots proclaimed as the answer to life's greatest health mysteries? Every food product in existence found a way to work oat bran into their recipes so that, overnight, we started seeing advertisements for "Chocolate Coated Sugar Bombs-NOW with Oat Bran" as if that somehow made the most toxic food an instant nutritional success. Phooey.

This mentality is not new to the computer industry. Every time a new language or methodology comes out, they proclaim that this solution provides better reuse than that solution, and the masses flock to the mount. Double phooey. Sure, the mythology of object software is that you get better code reuse, but let's take time to do a careful analysis and see what the reality looks like instead of blindly following the prophet.

You make a good case for the position that object reuse is primarily due to recycled analysis. Surely, in terms of the software life cycle, analysis and design are the largest pieces of the pie. Thus, it makes sense that any attempt to make that effort recyclable will reap great benefits in terms of shortening subsequent development times. But I think you're being a little short-sighted when you casually push aside programming and development in favor of maintenance and design.

You ask who cares? Did I fall asleep while the great Jeff Alger took a swan dive into the Twilight Zone? Surely software reuse is more than just a simple cocktail party discussion. In fact, how many developers using a good class library would claim that reuse ala class libraries does not affect time to market? Ask yourself, if you didn't use MacApp for the projects you've developed, would your time to market have been equivalent, longer, or shorter? The veterans of the object community can answer this in their sleep, indicating that there really is something to software reuse that we're not grasping here.

Your answer to why MacApp classes are reusable is that their context is limited. While this is true, let's see what that really means. Yes, MacApp is a good abstraction of a Macintosh application, concepts that are fairly common to all applications. Yes, it is not a perfect abstraction. This is not an indictment of the concept of reuse, but of the assumptions that went into MacApp design.

For example, remember the TDocument crisis of MacApp 2.x? In a nutshell, some developers had serious problems because TDocument had assumed that there was one file per document. Since many, but not all, applications had this model, many, but not all, applications lived happily with TDocument 2.x. This was a problem because the assumptions made by the MacApp 2.x design were violated by those multi-file per document apps, a classic case of what you yourself point out as the number one software problem: solving the wrong problem.

In 3.x there is another problem. Sure, TFileBasedDocument is great for those developers who have 1:1 file:document mapping, but TDocument leaves a lot to be implemented those who don't. Again, this is not an indictment of reuse, but of the design. Essentially, TDocument was not provided with a full framework to support file handling. Instead, there are methods which the developer can use to tap into their own framework.

But these examples are really edge cases. Overall, MacApp is an excellent example of the potential of object frameworks. Is it a set of software ICs? Of course not. Personally, I believe that the problem with software ICs is that the design of good object frameworks is still not understood as a general concept. Nonetheless, the examples we see each year get closer to the idyllic abstraction of the IC world.

And what's this tripe about software ICs constraining creativity? I think that good software ICs will only enhance creativity by allowing the developer to concentrate on the very essence of their area of interest. The framework in which the IC lives should provide support all concepts outside the region of interest of the developer. This is the promise of object technology. Using MacApp examples again, MacApp provides quite a bit of support for underlying Macintosh guidelines, file system idiosyncrasies, startup hassles, and event management to name a few. While not nearly perfect, this is still the best thing we've seen yet.

So where are we today? Reuse of object software isn't perfect, but we've already seen what its early incarnations can provide. And remember that that shrinking development time you quote may be due in large part to the effect of more and more software reuse.

Don't worry, we'll get there someday.

Highest stirring regards,

Eric