Subject: Reuse - is it for real?
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Tue, 26 Oct 1999 13:13:28 +0900 (JST)

>>>>> "Crispin" == Crispin Cowan <crispin@cse.ogi.edu> writes:

    Crispin> "Stephen J. Turnbull" wrote:

    >> This is an exaggeration, but all of the software management
    >> books I've read have referred to the great difficulty of
    >> achieving even 20% reusability, and even with substantial
    >> management backing.  Has this changed?

    Crispin> Open source does seem to be massively breaking this rule:

    Crispin>    * Closed source approach: we wanna build a Foo
    Crispin> application.  What object libraries are lying around that
    Crispin> we can re-use?  Oh, they do it that way.  Ah, skip it,
    Crispin> lets build our own with the right dinglefratz.

This assumes that Closed, Pty, has never build a Foo before.  If they
have, they do it the same way that Open & Sons does.  It's not clear
to me how much advantage this gives Open & Sons, given that

    o Closed Pty is likely to specialize in Foos, Frobs, and Frips.
      Thus pretty quickly most of the time they'll have a Foo or
      whichever they can reuse in the archives.
    o Random hacking is not likely to be directed toward user needs,
      but rather toward personal needs (nothing wrong with that, but
      it means that external benefits to Open Foo may be only marginally
      higher due to this effect).
    o If you need a Foo, first you have to find the Foo archive, then
      you have to decide whether a Perl/tk Foo or a C++/gtk Foo or
      Foo.el is what you want, and then you have to inspect the code
      to see if it's usable

    Crispin>    * Open source approach: I really like the Foo
    Crispin> application, but I wish it had a Bar feature. <hack hack
    Crispin> hack> There, now it has a bar feature.

The standard objection to this in the management literature is that it 
doesn't scale.

I can say, personally, having a lot of experience with a particular
Bar feature (Japanese input/output/massaging capability), that some
Bar features added by this approach

    o waste effort because the Bar programmer doesn't care about Foo's 
      design or coding standards, resulting in a new patch with every
      re-release of Foo
    o create lots of bad will in the community because of the politics 
      revolving around integrating Bar into the mainstream Foo code
      base.

In case you think you know what I'm talking about, let me add this
disclaimer:  I am not talking about the Emacs/Mule fiasco.  (See
X-Mailer header.)

    Crispin> This seems to result in a majority of code being re-used,
    Crispin> rather than a tiny minority.  The fundamental difference
    Crispin> is that GPL licensing of an entire program encourages
    Crispin> would-be developers to improve the original, rather than
    Crispin> re-invent the wheel *again* and *again*.

Well, anybody who is thinking about extending XEmacs, my advice is
"think twice".  _None_ of the major low-level components (redisplay,
Lisp interpreter, Mule) is close to state-of-the-art.  The XEmacs
redisplay code is as crufty and fragile as any legacy COBOL code (but
we are Y2K compliant as far as we can be ;-)

XEmacs, IMHO, is in immediate (12~24 months) danger of being
superceded by a combination of the Mozilla redisplay, a real widget
tool kit, a modern Scheme or Common Lisp interpreter, and a rewritten
from scratch multilingual facility.  Now, that would be an
order-of-magnitude efficiency gain from reuse!  Unfortunately, what I
mean by "danger" is feasibility; the economics motivate against
actually doing it right now although some XEmacs developers are
getting frustrated enough to blow off large quantities of steam about
it occasionally.

This is probably equally true of mainline GNU Emacs, despite the "new
redisplay" and lots of talk about replacing Emacs Lisp with Guile.  I
know that despite much more active development, the Emacs Mule is
pretty much as rickety as XEmacs's Mule.  (And why, pray tell, if free
software encourages reuse, is GNU writing yet another new redisplay
and yet another Scheme?)

I don't know if this characteristic of anything but XEmacs.  I do
consider it a warning, a parable if you will, against equating reuse
of more lines of code with more effective reuse of code.

    >> Yes, I know about the various libraries out there being
    >> actively developed.  Are you satisfied with the rate at which
    >> they're getting specified, designed, coded, and debugged, on
    >> average?

    Crispin> Satisfied?  I'm amazed.

Good for you.  I'm not satisfied.  I have 3 different tcl libraries
installed (two vanilla ones of different vintages and a Japanese one).
glibc is two minor versions (at least) behind schedule on integrating
Asian languages into the POSIX locale mechanism.  glibc breaks binary
compatibility between patchlevels.  XIM (input methods, mostly for
Asian languages) crashes mysteriously in Lesstif, various commercial
Motifs, and Xlib.

All of this has been going on for many months.  All of these have
workarounds, some I might even be able to fix myself with a block of
time.  I'm not complaining.  I am pointing out that known bugs the
developers don't care about don't get fixed.  This is no better than
the proprietary model where what the users don't pay for doesn't get
fixed, in terms of dedication to quality.

And I'm pointing out that it's precisely these details (precise
specification and accurate conformance to specification) that make
module-level reuse possible, and precisely these details that
developers most hate dealing with!  This doesn't support the
hypothesis of efficient reuse.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."