What Seems to be Working; Identifying Informal Reuse

Spending time and effort to closely analyze the full collection of existing reusable code in the legacy operating system, for example macros, module entry points and subroutines in any language, and to then document and measure them provides many benefits. It addresses the common problem of not having a robust repository of reusable parts for developers to use, as software reuse is introduced. If many parts are not available, willing participants in the introduction of software reuse have only one choice, to create new reusable parts. This often implies an investment larger than just writing new code[#!Ba87!#,#!BP90!#], an investment which is very difficult to justify. This "seeding" of existing parts creates a library of parts of unknown certification level [#!RT92!#], i.e. the desired or required level of documentation, quality, testing, legal information required of reusable parts by the local Reuse Board may or may not be met. These parts may be narrow in scope, and may not justify claims in productivity improvements, since reusers may know and use them anyway. But with respect to quality, existing parts have real customer-world history and data that can be used to identify and record known quality information of parts for reusers of those parts. This level of quality is difficult to achieve through extensive internal testing and quality verification of new code. What this repository of existing parts also provides to software developers is access to the new tools and new processes of software reuse, through the familiarity of software parts they have worked with for years. By making change as effortless as possible, people can adopt new habits of software reuse, i.e. looking for parts to use on a new project, "owning" a reusable part, and understanding documentation, quality, and test requirements of a reusable part. These habits will be required and will reap larger benefits as more formal and broader domain reuse is employed. As people understand through personal experience, the value, the tools, the requirements of good reusability, they will more naturally be lead to create software that is more reusable and less domain-specific when possible.

Scavenging of reusable components from existing software can be accomplished in many ways[#!CaB91!#,#!May91!#], and is likely more cost-effective than building new ones in an environment where the amount of existing legacy code that is maintained and enhanced far outweighs the amount of new code produced for the same software product. The EPL uses a set of reuse characteristics when manually scanning through existing code and when working with developers to identify reusable parts. This initial repository is further refined by examining encapsulation, domain breadth, frequency of current reuse, and known quality. Though only a subset of parts may be selected to make improvements based on these criteria and resource availability factors, all items remain on the list to be searched for by reusers. Once the repository of existing reusable parts is created, it becomes a repository of opportunity for quality improvement, reusability improvement, and certification of the reusable part. Domain experts and reuse experts can decide which parts need which work. For example, some parts may easily meet certification criteria once the quality history is checked. In other cases the documentation may need to be improved, and often, testing information needs to be found and recorded. With a tool to track which criteria are met and which aren't, it becomes easier to share the "costs" of certification, both among people and over time. A module owner, or one of the reusers, or a Reuse Board representative, or anyone could help with what they can afford to do in meeting certification criteria for a reusable part. Instead of requiring an author to do all these "extras" for some new reusable component and requiring them to fit it in with their development schedule now, it can be added to the repository, and mature to certification as it gets reused, or as time permits. We see this approach as an evolution of parts to the certified level, and an evolution of the organization to the broad employment of software reuse technology.