Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!mcsun!ukc!tcdcs!swift.cs.tcd.ie!vax1.tcd.ie!rwallace
From: rwallace@vax1.tcd.ie
Newsgroups: comp.sw.components
Subject: Re: What is a reusable software component?
Message-ID: <6796.26d6eadb@vax1.tcd.ie>
Date: 25 Aug 90 21:17:14 GMT
References: <27705@athertn.Atherton.COM> <533@helios.prosys.se> <27914@athertn.Atherton.COM> <6729.26c481cb@vax1.tcd.ie> <28772@athertn.Atherton.COM> <6775.26cdc403@vax1.tcd.ie> <1990Aug21.144152.3513@IDA.ORG>
Organization: Computer Laboratory, Trinity College Dublin
Lines: 98

In article <1990Aug21.144152.3513@IDA.ORG>, edwards@IDA.ORG (Steve Edwards) writes:
> 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.

True, and usually development time is more important than efficiency. However
in this case we're talking about a very small penalty in development time
(since it didn't take much longer to write my own routines than it would have
taken to figure out how to use third party ones) and a ridiculously huge
penalty in executable file size (rouch estimate is an increase from 100K to
400K, with corresponding losses in speed because the routines are slower and
you've got less memory to play with for disk caching etc.)

 

>> 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.
> 

Writing my own routines substantially improves maintenance time because I know
exactly what the routines do, they're custom written for this application and
the application code doesn't have to be forced into awkward contortions to
work with them, and most important they're much more reliable because they
contain much less code.
> 
>> 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?
> 

Maintenance and debugging effort increase as something like the square or cube
of the number of lines of source code involved. My routines contain _orders of
magnitude_ less code than their third party equivalents (e.g. all my screen
handling routines for overlapping windows, data entry and verification,
scrolling etc. are only a few hundred lines of code; a normal third party
package would be at least several thousand). The effort of debugging my
routines is completely trivial because they're so simple. This improvement in
reliability is another reason why writing my own routines reduces maintenance
costs.

"To summarize the summary of the summary: people are a problem"
Russell Wallace, Trinity College, Dublin
rwallace@vax1.tcd.ie