Path: utzoo!attcan!utgpu!craig From: craig@gpu.utcs.utoronto.ca (Craig Hubley) Newsgroups: comp.sw.components Subject: Re: What should a component library loo Message-ID: <1989Nov25.071921.8234@gpu.utcs.utoronto.ca> Date: 25 Nov 89 07:19:21 GMT References: <130200021@p.cs.uiuc.edu> <7095@hubcap.clemson.edu> Organization: University of Toronto Computing Services Lines: 149 >(William Thomas Wolfe, 2847 ) writes: > > This assumes that everyone can unilaterally decide to produce > components which are large enough to justify reuse, which is > contradictory to the assumed software engineering methodology. > ^^^ Generally, reusable components must be more reliable than those intended to be used once - more effort must be put into making them *correct* and creating *robust* versions (two different things!). The additional resources to do this should probably be allocated centrally, on a priority basis, by someone with organization-wide responsibility. > In order to reduce the chaos which would result if everybody > could create components on their own, each required component > ^^^^^^^^ Re-use is an incremental thing. Casual re-use implies that a piece has been *found* that is useful. Organized re-use implies that a piece has been designed to be reusable. Both kinds require a central registry for reusable or potentially reusable code. A set of simple metrics like 'how many projects has this been used in' is probably a good starting point for determining 'how' reusable something is. There is also the issue of whether a class/library designer should be required to support a class for the use of others, or whether that responsibility should pass to the central registry. > is identified in the detailed design phase and the librarian > ^^^ > provides information regarding the match (or lack thereof) > between the component requirements and the component supply. Don't forget that the librarian should be looking *first* for appropriate libraries outside the organization, presumably produced and maintained by those whose primary business is producing and maintaining *that* library. To do otherwise is to dilute effort into areas others have already covered adequately, and diminish the value-added of one's own product. The same organization-wide position should be responsible for purchasing libraries from outside, or commissioning their development into reusable code inside. >The highlighted words imply a particular scenario for the library and the >software development environment that it's imbedded in. I can envision a >number of reasonable organizational and procedural arrangements that would >lead to different degrees of "coupling" between the producers, librarian, >and consumers. Could you elucidate your assumptions in the above statement? Since I've butted in on this :-), I should at least explain my own assumptions: 1. Central registry and resources for reusable software are crucial. Word of mouth is not adequate publicity, and casual change/fix requests are not adequate support for reusable code. 2. If reusable code emerges from a project not specifically oriented towards producing it, that is a nice coincidence, but if code is to be supported across more than one project that must be a concious decision - other decisions, such as to buy that particular functionality for later projects, are certainly possible and must be considered carefully. A lot of resources can be consumed making code correct and robust. Someone must be made responsible for supporting the code in its new, general, role, and resources must be available for that - at first, very substantial resources, as the culture of re-use has to be built and encouraged. 3. 'Correct' code responds correctly to correct input. 'Robust' code responds predictably to incorrect input. 'Robust' versions of code can be derived from 'correct' versions, as they retain the same interface and only add some error-checks. The two versions can then be used interchangeably as the situation demands. Usually both must be available for real reusability. 4. In larger organizations (more than 10 people!) a microcosm of the larger set of roles can be mirrored for projects or groups of projects. Someone may be responsible for searching the organizational code resources for items useful in the current project. Someone else may be responsible for specializing these. The central registry may decide if the specializations, or any new code generated, should be included in the organizational resources. This may sound bureacratic but it's the way other forms of information resources are re-used in organizations (legalese, business letters, insurance policies, etc.) >Having made this request, I guess it's only fair to expose the model that >I'm assuming. I'm thinking of a software development organization that >produces "products" (where the consumers may be outside customers or >internal users), and has several projects going on at once (some of which >may be related). Rather than having a separate group of "component >producers", components would be produced as spinoffs of normal development >activity. This would, of course, involve some overhead (from the point of >view of the project manager) to either plan or retrofit the desired >qualities into the component. I'm not advocating this as the only way to >go, but it seems like a reasonable initial goal for a multi-project >organization. The danger with this should be clear by now - the project manager is not being encouraged or rewarded to design good reusable code - quite the opposite. His/her project deadlines and costs are being impacted by an activity that he/she has no resources or incentive to support. Planning and retrofitting are both time-consuming activities, and when you consider that the interface to the basic code facilities of the project are the first bottleneck any project runs into... A useful alternative would be to identify certain key projects as likely to produce large portions of reusable code. These should not be projects that are business-critical or have tight deadlines. Ideally, they should almost be 'optional' or 'CEO pet projects' with low consequences for failure. A group of people ready to risk some prestige for the sake of getting involved with a new technology, perhaps a group with something to prove or make up for, might make the best team. It should be emphasized from the beginning that the degree to which their work is re-used will be a crucial factor in evaluating the project - perhaps more so than the final result. All of this should be visible to the team from the beginning. This group may later become your corporate component library. Without such projects available, another possibility would be to create a group to work with project managers and designers in the early stages of *all* projects. Such a group would need expertise in every application area that the company works in, because they would need to evaluate the potential for re-use of every piece of code produced by every project. With their help, the project manager should be able to define interfaces early enough to stay on deadline. For co-operating, some incentive such as increased administrative resources (for those extra phone calls!), longer deadlines (if a project can't come in two weeks later to serve a major long-term goal, your company is already in trouble), conference/training support, or even some fun money (an interesting excursion at the organization's expense). In any case, it is necessary to back up the corporation's interest in this long-term goal with some visible support. The more visible the better. >Unfortunately, I haven't received Johnson's message, and I'd rather not >comment on an excerpt out of context, but I will say that having more than >one implementation for a given spec can be useful for more than performance >reasons (portability to radically different environments, for example). Essentially the 'correct' vs. 'robust' distinction is two implementations on what is really the same spec (most specs don't include error recovery). I agree that the inheritance matrix is an implementation mechanism, and if I could build a separate one for the users (of my library) to see, I would. The functional relationships may not be identical to the implementation matrix. >Don Dwiggins "Solvitur Ambulando" >Ashton-Tate, Inc. Craig Hubley ------------------------------------- Craig Hubley & Associates "Lead, follow, or get out of the way" craig@gpu.utcs.utoronto.ca ------------------------------------- craig@gpu.utcs.toronto.edu mnetor!utgpu!craig@uunet.UU.NET {allegra,bnr-vpa,decvax,mnetor!utcsri}!utgpu!craig craig@utorgpu.bitnet -- Craig Hubley ------------------------------------- Craig Hubley & Associates "Lead, follow, or get out of the way" craig@gpu.utcs.utoronto.ca ------------------------------------- craig@gpu.utcs.toronto.edu mnetor!utgpu!craig@uunet.UU.NET