straub@jogger.cs.umd.edu (Pablo A. Straub) (06/17/91)
In article <1991Jun14.152529.1@east.pima.edu> rharwood@east.pima.edu writes: > > OK... maybe we can LIGHTLY (read as: "without flame") discuss and > subsequently define what reuse really IS (or ought to be!). > > My Personal Opinion: Calling a DBMS or GUI or math routine is NOT > reuse. Libraries of complex mathematical subroutines have been > available to FORTRAN programmers since ENIAC, I suppose. Perhaps > "reuse" is truly short-hand for "source code reuse"? The term has > mostly come to represent the ability to incorporate software written > for or funded by "some other" project with little or no modification; > perhaps some customization (specifically, the instantiation of an Ada > GENERIC unit for the target elements). > > Ray Harwood I hope reuse is not seen only with respect to code. The prospects are much wider. First, most people informally reuse all sorts of documents, including specifications, design, code, test suites, end-user documentation, estimates, you name it. For a more effective reuse of documents people invest in reuse, for example creating parameterized documents (parameters for a subroutine, generic parameters, macros for documents, etc.), designing for reuse, training for reuse, etc. Second, you most people reuse the processes that created those documents, simply by learning from experience. For a more effective reuse of processes few :-( people actually record their process (e.g., a developer's manual for their organization). If the process is extremely well structured, then it can recorded as a program whose parameters represent particular instantiations of the development process--and a brand new software generator is born. :-) Hence we can view the use of a 4GL as reuse of some development process. BTW, it's nice to have part of your product funded by other project, but if that's the only way we are to reuse there won't be much investment in software. Pablo Straub
jls@netcom.COM (Jim Showalter) (06/18/91)
>I hope reuse is not seen only with respect to code. The prospects are >much wider. I agree. What you seem to be advocating might be called "structured laziness", and I'm all for it. Remember the maxim: "An engineer is a person who can do for a dime what any damn fool can do for a dollar". >few people actually record their process (e.g., a >developer's manual for their organization). Actually, I've encountered a number of organizations that record their process, it's just that what they write down bears no resemblance to what they actually DO. Their developer's manual is a work of fiction... >BTW, it's nice to have part of your product funded by other project, but >if that's the only way we are to reuse there won't be much investment in >software. Depends. It is certainly unreasonable to expect a manager responsible for the success of a SINGLE project to think beyond the immediate horizon, but the job of that person's MANAGER (or manager's manager) is to think about the business as a whole--and from the standpoint of an entire line of business, it is idiotic NOT to reuse code across as many projects as possible. Some companies are starting to realize this and will wind up, as a consequence, having a competitive advantage over those who have not yet figured this out. -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *