Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!samsung!sol.ctr.columbia.edu!IDA.ORG!edwards From: edwards@IDA.ORG (Steve Edwards) Newsgroups: comp.sw.components Subject: Re: What is a reusable software component? Summary: maintenance is the key Message-ID: <1990Aug21.144152.3513@IDA.ORG> Date: 21 Aug 90 14:41:52 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> Reply-To: edwards@IDA.ORG.UUCP (Steve Edwards) Organization: IDA, Alexandria, VA Lines: 138 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