Xref: utzoo comp.object:3135 comp.software-eng:5326
Newsgroups: comp.object,comp.software-eng
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!m.cs.uiuc.edu!cs.uiuc.EDU!johnson
From: johnson@cs.uiuc.EDU (Ralph Johnson)
Subject: Re: How to pay for reusable software
Message-ID: <1991Apr12.182420.18587@m.cs.uiuc.edu>
Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
Nntp-Posting-Host: m.cs.uiuc.edu
Reply-To: johnson@cs.uiuc.EDU (Ralph Johnson)
Organization: University of Illinois
References: <1991Apr3.231849.13410@m.cs.uiuc.edu> <3318:Apr705:51:2391@kramden.acf.nyu.edu>
Date: Fri, 12 Apr 91 18:24:20 GMT
Lines: 50

In article <3318:Apr705:51:2391@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
|> 
|> The problem in software today isn't code that's written once. As you
|> observed, it is absolutely pointless to take a unique section of code
|> and make it reusable---or even to start by writing it reusably.
|> 
|> But as soon as the code is written twice, it should never have to be
|> written again. As soon as you see that you're *reusing* software, you go
|> back, make the original *reusable*, and then *reuse* it. Any competent
|> programmer will assume that what he uses twice, he'll use again, and so
|> he'll put in the extra effort so that it's easy to use.

I agree that you should never try to write reusable software unless
you have already written the software once.  It takes a lot of experience
with the application domain to understand what abstractions are important,
There are a few areas, such as data structures, parsing, and now user
interfaces, where there is a lot of community experience and you can
learn about the application domain from books, but that is not common.
The right way to develop reusable software is to generalize from a couple
of non-reusable versions.

However, I disagree that this solves the problem.  Often it is not the
components (i.e. subroutines or data structures) that you want to
reuse, but higher level patterns and the overall architecture of the
program.  It is difficult to detect these patterns and to abstract them
successfully.

Putting it another way, you are never going to get InterViews by simple
rewriting of X-based programs.  

In any case, my experience (and that of many others) is that you
have to reuse software two or three times (in addition to the one
or two times that it took to recognize its value in the first place)
before all the "reusability bugs" are out.

Many corporations have recognized the value of reusable software and
are developing their own libraries.  Sometimes this is the best
strategy, especially for narrow application domains in which they
have, and want to keep, a dominant position in the marketplace.
However, a lot of what is being put in these libraries is the same
as what everybody else is putting in.  We would be a lot better off
developing industry standard packages that students could learn, to
minimize the cost of retraining new programmers, and to reduce the
overall cost of software.  There is a lot of reuse going on within
single companies, but the marketplace for reusable software is not
nearly as large as lots of people thought it would be.

Is the marketplace for reusable software destined to be small?

Ralph Johnson -- University of Illinois at Urbana-Champaign