March 93 - Reuse Abuse
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