70 APPROACHES TO REUSABILITY $4.2 In discussing reusability and reusability policies you should always make sure which one of these two views you have in mind.In particular,if your organization is new to reuse,remember that it is essentially impossible to start as a reuse producer.One often meets managers who think they can make development reusable overnight,and decree that no development shall henceforth be specific.(Often the injunction is to start developing"business objects"capturing the company's application expertise,and ignore general-purpose components-algorithms,data structures,graphics,windowing and the like-since they are considered too"low-level"to yield the real benefits of reuse.)This is absurd:developing reusable components is a challenging discipline;the only known way to learn is to start by using,studying and imitating good existing components.Such an approach will yield immediate benefits as your developments will take advantage of these components,and it will start you,should you persist in your decision to become a producer too,on the right learning path. Reuse Path principle Here too "Object Success”explores Be a reuse consumer before you try to be a reuse producer. the policy issues further. 4.2 WHAT SHOULD WE REUSE? Convincing ourselves that Reusability Is Good was the easy part (although we needed to clarify what is really good about it).Now for the real challenge:how in the world are we going to get it? The first question to ask is what exactly we should expect to reuse among the various levels that have been proposed and applied:reuse of personnel,of specifications,of designs,of"patterns",of source code,of specified components,of abstracted modules. Reuse of personnel The most common source of reusability is the developers themselves.This form of reuse is widely practiced in the industry:by transferring software engineers from project to project,companies avoid losing know-how and ensure that previous experience benefits new developments. This non-technical approach to reusability is obviously limited in scope,if only because of the high turnover in the software profession. Reuse of designs and specifications Occasionally you will encounter the argument that we should be reusing designs rather than actual software.The idea is that an organization should accumulate a repository of blueprints describing accepted design structures for the most common applications it develops.For example,a company that produces aircraft guidance systems will have a set of model designs summarizing its experience in this area;,such documents describe module templates rather than actual modules.70 APPROACHES TO REUSABILITY §4.2 In discussing reusability and reusability policies you should always make sure which one of these two views you have in mind. In particular, if your organization is new to reuse, remember that it is essentially impossible to start as a reuse producer. One often meets managers who think they can make development reusable overnight, and decree that no development shall henceforth be specific. (Often the injunction is to start developing “business objects” capturing the company’s application expertise, and ignore general-purpose components — algorithms, data structures, graphics, windowing and the like — since they are considered too “low-level” to yield the real benefits of reuse.) This is absurd: developing reusable components is a challenging discipline; the only known way to learn is to start by using, studying and imitating good existing components. Such an approach will yield immediate benefits as your developments will take advantage of these components, and it will start you, should you persist in your decision to become a producer too, on the right learning path. 4.2 WHAT SHOULD WE REUSE? Convincing ourselves that Reusability Is Good was the easy part (although we needed to clarify what is really good about it). Now for the real challenge: how in the world are we going to get it? The first question to ask is what exactly we should expect to reuse among the various levels that have been proposed and applied: reuse of personnel, of specifications, of designs, of “patterns”, of source code, of specified components, of abstracted modules. Reuse of personnel The most common source of reusability is the developers themselves. This form of reuse is widely practiced in the industry: by transferring software engineers from project to project, companies avoid losing know-how and ensure that previous experience benefits new developments. This non-technical approach to reusability is obviously limited in scope, if only because of the high turnover in the software profession. Reuse of designs and specifications Occasionally you will encounter the argument that we should be reusing designs rather than actual software. The idea is that an organization should accumulate a repository of blueprints describing accepted design structures for the most common applications it develops. For example, a company that produces aircraft guidance systems will have a set of model designs summarizing its experience in this area; such documents describe module templates rather than actual modules. Reuse Path principle Be a reuse consumer before you try to be a reuse producer. Here too “Object Success” explores the policy issues further