Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!hacgate!ashtate!atsun!dwiggins From: dwiggins@atsun.a-t.com (Don Dwiggins) Newsgroups: comp.sw.components Subject: Re: Reasons for low reuse Message-ID: Date: 12 Sep 89 19:02:24 GMT References: <60116@tut.cis.ohio-state.edu> Sender: dwiggins@ashtate Organization: Ashton-Tate, Inc. Lines: 41 Being real process-oriented lately, I'd like to put this reuse discussion in a broader setting. Many assertions have been made about the possibilities and issues of reuse, each based on unstated or only partially stated assumptions about the process and setting of the supposed act of reuse. In fact, there can be many such settings, each implying different constraints and characteristics of the components, the collection of them, and the "reuser". For example, The personal toolkit: an experienced machanic collects high-quality tools, assumes responsibility for them, and takes them with him/her. Having created a module to solve a problem, an experienced software engineer might well generalize the solution a bit, polish the implementation and the interface description, and drop it in the kit. The corporate resource: rather than continually reinventing solutions to recurring problems, the company creates a library and supporting staff to capture the solutions and make them available to new projects. Note that there's likely some domain leverage here; the company's projects will often cover a lot of the same ground. The commercial product: this is what seems to have been the assumption behind most of the discussions so far. Even here, there are many possible relationships among the component and library creators, sellers, and buyers, and probably many possible types of "component" (how about selling detailed designs or generic sources like MacApp?) In all these settings, I think that the major problems are organizational, psychological, and institutional -- meeting the differing goals of the various folks involved. It'll probably take some "process prototyping" to work these out. The technical problems that arise will be solved as part of all this (and some technical issues will turn out to be non-problems). What I'd like to see is some reuse success and horror stories along this line: what was the setting and process, how did it work out, what problems arose and how were they solved (if they were)? -- Don Dwiggins "Solvitur Ambulando" Ashton-Tate, Inc. dwiggins@ashtate.uucp