Xref: utzoo comp.object:3071 comp.software-eng:5289 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!phoenix!egnilges From: egnilges@phoenix.Princeton.EDU (Ed Nilges) Newsgroups: comp.object,comp.software-eng Subject: Re: How to pay for reusable software Message-ID: <8028@idunno.Princeton.EDU> Date: 8 Apr 91 16:39:02 GMT References: <1991Apr3.231849.13410@m.cs.uiuc.edu> <6761@stpstn.UUCP> Sender: news@idunno.Princeton.EDU Followup-To: comp.object Organization: Princeton University Lines: 50 In article <6761@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > >I believe the demand for a market in reusable components is high, but >the supply is low, because of exactly what Ralph has identified; that >the costs of building reusable components is extremely high, higher >than those who have not tried to do this for a living is probably >realize. Darn right, Brad. As one who frequently gets into hot water for spending too much time making things reusable, I find that reusability is quite beneficial in ways that cannot always be quantified or cost-justified. Especially in contract programming, you are paid to do exactly what the customer wants, and it is the kiss of death to bill for reusable software. Nonetheless, a software system built out of reusable components seems always to work better and to be easier to maintain than one that is not so built, once you've tuned critical sections for efficiency. I am currently working on reusable environments in C and in REXX. REXX is a language for writing glue procedures in the IBM mainframe environment that is also useful for general programming and which also has implementations on the Amiga, the PC and unix. REXX at this writing is mostly interpreted. I find that it is much easier to make things reusable in REXX, because writing a reusable tool has only these steps: 1. Document 2. Code 3. Test using a standard harness (called TRY) which displays the before and after environment 4. Place on public disk Note that we document prior to coding. Normally, these components are so simple that this phase is the analysis phase in which we determine our requirements. Note, also, that these are NOT end-user tools: if they were, a "step 0" requirements phase would have to be added. To do a needs determination for these types of tools, we talk to ourselves. Developing C reusable components of equivalent simplicity is a con- siderably more daunting task in that we are using a compiler. This means that we have to set up libraries and worry about porting issues that do not arise in REXX. This does not mean that it is a waste of time to develop reusable C, just that it's more expensive in ways that the theoreticians do not see.