Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.software-eng
Subject: OOP and software reuse
Message-ID: <39400113@m.cs.uiuc.edu>
Date: 8 Jul 90 04:45:00 GMT
Lines: 107
Nf-ID: #N:m.cs.uiuc.edu:39400113:000:6102
Nf-From: m.cs.uiuc.edu!johnson    Jul  7 23:45:00 1990


This article is a response to one by cliffhanger@cup.portal.com (Cliff Heyer).

First, let me say that I agree with Cliff's main point, that
building software is research and not construction.  There are
some people for whom building software is construction.  They
keep building the same software over and over again.  These
people are mostly in data processing shops.  They are the people
how should be using 4th generation languages.  Or, put another way

/However, these guys should be reusing software instead of rebuilding
/it.
to which Cliff replied:
>Try it sometime, it's not as easy as you think.

He then went on to say why software reuse will not happen.

I am a Smalltalk programmer.  Almost by definition, this means
that I reuse software everyday.  Sometimes I reuse it in small
chunks, like a sequence or a set.  Sometimes I reuse it in large
chunks, like a drawing package.  I'm an academic, so I can't tell
you how I beat my competitors to market and make lots of money,
though I've heard plenty of commericial people who use Smalltalk
say that, and I know that my students tend to build their research
systems a lot faster than other faculty expect.

As you might think, I take a dim view of arguments that reuse
is impossible.  Cliff's argument about the date validation function
assumed that the routine was not flexible enough and could not be made
more flexible because source was not available.  This just implies that
either software has to be flexible enough or it has to be extensible,
i.e. you have to be able to extend it when needed.  I share Cliff's
view that no one software package is going to be flexible enough to
meet everybody's needs, so that means that reusable software has to be
extensible.  This is certainly no surprise to an object-oriented programmer.

Actually, I have never reused software without source.  I am not sure
that I could, or that I would want to.  Unlike Brad Cox, I think that
a successful reusable components business will depend on source code.
Although it is theoretically possible to document classes well enough
that they can be extended without access to their source, it seems much
more likely that people will just sell the source and not improve their
documentation standards.  As people have explained, really good documentation
is as hard as or harder to write than good code.  Current documentation is 
good enough most of the time, and when it isn't I can read the source.

I think that many people, including Cliff, do not quite understand what
we mean by "building software from reusable components".  We do not mean
that every line of the program is reused.  Although my goal in creating
a class library is to make it so flexible that it can be reused without
further programming, that is an impossible dream.  Even well developed
class libraries, such as those for user interfaces, require programming
to use.  There are quite a few Smalltalk applications that do not require
any new user interface classes, but can be built entirely from the standard
classes.  However, more often than I'd like, I have to make a subclass of
View or of Controller.  In one sense, I'm still reusing software, because
a subclass inherits a lot of code from its superclasses.  However, I
have to create new classes and write code for them, and so it is not
as simple as "plugging objects together".

Even when I don't have to write any user interface classes, I have to
write application classes and hook my objects up to user interface objects.
Thus, I always have to write code.  Getting the user interface "for free"
means that I save a lot of time that I can use for building another system.

The purpose of software reuse is not to eliminate programming but to
eliminate *unnecessary* programming.  Although some of what we do
when we design new systems is creative, some of it is routine, simply
regurgitating algorithms and data structures that we have learned
in the past.  Software reuse lets us stop regurgitating.  In other
words, it will eliminate that part of building software that is
predictable and so emphasize the creative part that is not predictable.
In that sense, object-oriented programming is going to make the problem
that Cliff mentions worse.  However, it will greatly decrease the amount
of time that it takes to build software.  Managers still won't know how
much time it takes to build software, but they will know that it takes
less time than it used to.

Reducing the time it takes to build software by an order of magnitude
can have a very big impact on the way one develops software.  Iteration
and rapid prototyping are preached by the Smalltalk community because
they *can* build prototypes rapidly.  I think that the managerial
implications will be profound, but I don't think anybody understands
them yet.

There are lots of unsolved problems with OOP and software reuse.
Writing reusable software is very hard, it is just reusing it that
is easy.  We need to figure out how to make a marketplace for
components, since that seems to be happening very slowly.  We need
to figure how to manage OOP projects, how to test OOP systems, how
to document them, etc.  Thus, I am not claiming that OOP will solve
all your problems, but I do claim that it will give you a big enough
advantage that everybody will be using it in the future.

I'll finish with a story.  I met a fellow on an airplane to San Francisco
who was a consultant with belt-way bandits.  He was a Smalltalk programmer,
and he would build the prototypes that the belt-way bandits would use
when they were trying to sell the military on their project.  He said
that he would spend the morning talking to his customer and spend the
afternoon building a prototype.  The next morning, he would show it to
the customer, find what they didn't like, and make another iteration.
Most customers were completely blown away the first time he returned
with an executable prototype, since they expected another question and
answer session, not a demo.  I imagine he has lots of repeat customers.


Ralph Johnson -- University of Illinois at Urbana-Champaign