🚀 go-pugleaf

Well, I've been listening to this discussion from the sidelines for a
while, but I finally decided to interject a few thoughts.

In article <6775.26cdc403@vax1.tcd.ie>, rwallace@vax1.tcd.ie writes:

> In the library yes. However for the reasons given above, with current
> compilers it'll [extra functionality] be in the executable as well,
> wasting space.

True.  Of course, one man's wasted space is another's investment in
future expandability.  Isn't writing a custom version of the component
to address this problem ``wasted effort''?  It all depends on your
perspective.

It is very important to know that there are many ``costs'' that come
along with reusable software.  The extra code it may insert into your
image, the extra execution time it may impose over a more optimized
version of the same module written for a specific application, the
extra complexity added to the interface by code and functionality
you don't need at the moment, and so on.  Tools (like the smart
linkers discussed in the above message) can help to reduce some of these
costs, but they certainly don't make the central difficulty go away.
Deciding whether to reuse a specific component or write a custom
version is a tradeoff--do the costs of reusing outweigh the benefits
you get from reusing (measured in savings, of course)?  I'll
discuss the benefits a little bit more below.

> I don't agree. I think reusable software components could be useful in most
> applications, but to produce acceptable efficiency such compilers need
> to come into general use.

Again, what is ``acceptable''?  The important point is that it's
_relative_ to the tradeoff mentioned above.  The efficiency penalty
is a cost.  What are the real efficiency requirements for the thing
your building?  Those requirements may drive strict boundaries on how
much inefficiency (in time, space, or whatever resource you choose to
name) you can ``accept.''  Then, its a matter of whether that efficiency
penalty buys you a ``useful'' amount of benefit from reusing.  Again,
``useful'' is relative as well.

> 1. _The_ advantage of reusable software components is that it reduces
> software development time, at least if the tendency to overcomplicate
> things is controlled. As I explained, this advantage is becoming less
> and less relevant as developers put more and more unnecessary junk
> into their products.

This is the central statement with which I disagree.  I think _way_ too
much emphasis has been placed on the development savings that reuse
offers.  In fact, the _real_ cost of developing software on a large
scale isn't development at all (particularly not the cost of writing
the code).  It's _maintenance_.

Sure, reuse allows you to ``share'' the cost of developing a component
with other people (particularly the guy who wrote it originally), and
you come out on the winning end of this deal.  But for large projects,
the maintenance cost really dwarfs the development effort (typical
estimates for large projects place maintenance at 70% of total life
cycle costs, sometimes more).  But reuse also lets you ``share'' the
cost of finding and repairing bugs (if all the right reuse library
mechanisms are in place, of course), and of performing maintenance.  This
sharing can be spread over all past, current, and future users.  Thus,
over time reusable components become much more robust and bug free because
of the accumulating investment in their maintenance.  And new users get
to share in the benefits of this investment.

Although many developers in smaller projects fail to see these
ramifications, I believe they are the most important benefits reuse
has to offer.  And more importantly, they have to be figured into the
``to reuse or not to reuse'' tradeoff before you decide whether or not
to reuse.

> 2. I can make my routines as bug free as a reusable component
> developer, and consider: If there's a bug in one of my routines, I
> can fix it on the spot. If there's a bug in a routine supplied by
> someone else to which I don't have the source, I have to wait for
> an upgrade.

_Given enough $$$$_, this is true.  The point is that reuse provides the
opportunity for all the reusers of a component (past and present) to,
in effect, pool their maintenance resources to get this level of quality.
While I'm sure you're capable of debugging a component as well as the
next guy, how much money can your project pour into debugging (during
development), and then how much more during maintenance?  Why is this
duplication of effort (if an acceptable component is available)
necessary?

It's always possible that for any given module, the tradeoff will swing
towards writing a custom version.  In fact, in the MSDOS world, where
efficiency and size are premium concerns and few good components are
available, this is likely to be the most common case today.  But you
have to actually think about everything involved and make an _educated_
tradeoff.  It's not good engineering to make that decision
``just because'' ...

Your second point, about availability of source code, is a different
issue.  It's specific to a given component and a given vendor, and
has to be taken into account when deciding whether to reuse
_that component_.

> 3. Two examples: First, screen display routines. My routines are much more
> efficent than anyone elses because mine just transfer data direct to video
> RAM while other people's routines have to cope with things like linefeed
> and beep characters.

Again, is this efficiency _required_? [I'm not asking this about your
particular application specifically, just trying to make a point]  If it
is, then that's an important factor in deciding whether to reuse.  If
_not_, then it _should not_ drive the decision alone!  Again, remember
that in the MSDOS world, things can be very different than in a different
application environment.  Just because certain requirements exist in
one doesn't mean those requirements (for image size, for example) are
universal.

Well, I hope this didn't sound too much like a flame--I didn't intend
it to be one.  I was just trying to provide a few more ideas for
discussion.

Since I haven't posted here recently, I'll also include just a little
bit about myself so that you know where my ideas are coming from.  I'm an
Ada programmer, although I programmed in C years before that.  I've
participated in many small/medium-size Ada projects (i.e., each about
50KSLOC), all of which included at least some reusable components. I'm
also currently working on a paper about software reuse in Ada, including
many of these ideas, as part of a government-sponsored research project.
Needless to say, these opinions are mine, and not my company's
(or our sponsor's).


		    -- Steve

-------------------------------
Stephen Edwards
Institute for Defense Analyses
5111 Leesburg Pike
Suite 300
Falls Church, VA 22041
(703)845-3536
edwards@ida.org