Reuse is a long-term strategy in which an organization builds a library of frequently used components, allowing new programs to be assembled quickly from existing components. When backed by long-term management commitment, Reuse can produce greater schedule and effort savings than any other rapid-development practice. What's more, it can be used by virtually any kind of organization for any kind of software. Reuse can also be implemented opportunistically, as a short-term practice, by salvaging code for a new program from existing programs. The short-term approach can also produce significant schedule and effort savings, but the savings potential is far less dramatic than with Planned Reuse.
Efficacy
Potential reduction from nominal schedule: | Excellent |
Improvement in progress visibility: | None |
Effect on schedule risk: | Decreased Risk |
Chance of first-time success: | Poor |
Chance of long-term success: | Very Good |
Major Risks
Wasted effort if the components that are prepared for reuse are not selected carefully
Major Interactions and Trade-Offs
Reuse needs to be coordinated with productivity-tool use.
Planned Reuse must be built on a foundation of software-development fundamentals.
Reuse is sometimes thought to apply only to code, but it can involve reusing anything from a previous development effort—code, designs, data, documentation, test materials, specifications, and plans. For IS applications, planning for data reuse can be just as important as planning for code reuse. Although you might not think of it as reuse, reusing personnel from similar projects is one of the easiest and most potent kinds of reuse.
For purposes of this chapter, there are two basic categories of reuse:
Planned Reuse
Opportunistic Reuse
Planned Reuse is what experts are usually talking about when they refer to reuse, but Opportunistic Reuse can provide schedule reductions too. Opportunistic Reuse breaks down into two topics:
Reuse of components from internal sources
Reuse of components from external sources
Use of external components is not typically thought of as reuse; it's usually thought of as a buy-vs.-build decision. But the issues involved are similar, so I discuss some aspects of that topic in this chapter.
Reuse produces its schedule savings for the obvious reason that it's often quicker, easier, and more reliable to reuse something that's already been created than it is to create that thing anew. You can employ Reuse on projects of virtually any size, and it is as appropriate for in-house business systems as it is for mass-distribution shrink-wrap or systems software.
The considerations involved in Opportunistic Reuse and Planned Reuse are quite different and are discussed in the next two sections.
You can reuse opportunistically when you discover that an existing system has something in common with a system that you are about to build. You then save time by salvaging pieces of the existing system and using them in the new system.
If you want to reuse opportunistically, you have two options: adapt the old system to the new use, or design the new system from the ground up and salvage components from the old system. I have found that it works best to create a fresh design for the new system and then to salvage parts from existing systems. The reason that approach works better is that it requires you to understand only small pieces of the old program in isolation. Adapting an old program to a new use requires you to understand the whole program, which is a much harder job. Of course, if the people who wrote the old program are the same people who are working on the new one, or if the new one is extremely similar to the old one, you might be better off adapting the old program.
The salvaging approach is opportunistic because it takes some luck to be able to reuse designs and code from a previous system without planning ahead for it. You can succeed if the old system is well-designed and well-implemented. It helps if the old system made use of modularity and information hiding. You can also succeed if the staff overlaps between the old system and the new one. Without some overlap, trying to salvage parts of an old system can be more an exercise in cryptography than reuse.
The biggest problem with Opportunistic Reuse is that it is easy to overestimate potential effort and schedule savings. Even if the old system is quite similar to the new one—say, 80 percent of the code could potentially be reused—you have to consider requirements analysis, design, construction, test, documentation, and other activities in your effort and schedule planning. Depending on the specific situation, you might be able to reuse all of the requirements analysis and design or none of them; if the old project was not created and packaged to be reused, you should count on reusing none of them. If the code is the only thing that you can reuse, that 80-percent overlap in code can shrink to a 20-percent reduction in effort and even less reduction in schedule, even though the systems are 80-percent similar.
Part of the work of reusing 80 percent of the code will be figuring out which 80 percent to reuse. That can be deceptively time-consuming and can quickly eat into the 20-percent savings.
Another common problem occurs when parts of the old system are used in ways that weren't anticipated in the old system's design and implementation—new defects surface in the old system's code. When that happens, if your staff isn't intimately familiar with the old system, they suddenly find themselves debugging and fixing unfamiliar code, and that will eat into that 20-percent savings too.
Some projects that have reused opportunistically have had good success. A project done for the French military produced a 37-percent improvement in productivity by salvaging code from a similar existing system (Henry and Faller 1995). Project leaders credited the project's success to the use of modularity and information hiding in the first system, similar scopes of the old and new systems, and half of the same staff working on the old and new systems.
A study at NASA's Software Engineering Laboratory studied ten projects that pursued reuse aggressively (McGarry, Waligora, and McDermott 1989). The initial projects weren't able to take much of their code from previous projects because previous projects hadn't established a sufficient code base. In subsequent projects, however, the projects that used functional design were able to take about 35 percent of their code from previous projects. Projects that used object-based design were able to take more than 70 percent of their code from previous projects.
One of the advantages of this kind of reuse is that it doesn't necessarily require high-level management commitment. Capers Jones reports that individual developers often reuse their own code, which can make up 15 to 35 percent of any given program (Jones 1994). You might be able to encourage developers to reuse as much as possible at the technical-lead or individual-contributor level.
There isn't any technical reason to develop a component internally when you can buy a packaged component externally, but there might be a business reason, such as wanting to control a technology that's critical to your business. From a technical point of view, an external vendor can probably put more resources into a packaged component than you could and do it at less cost to you. Reusable code modules are typically offered at from 1 to 20 percent of what they would cost the customer to develop (Jones 1994).
For a lot of people, the free market is moving quickly to address reuse. It's been the subject of industrial and academic research for years, and vendors have long provided commercial code libraries for specific application domains such as user interfaces, databases, mathematics, and so on. But commercial reuse finally began in earnest on the PC platform with Microsoft Visual Basic and VBXs (Visual Basic Controls). Recognizing their popularity, Microsoft strengthened support for reuse with OCXs (OLE Controls). Language providers such as Borland, Gupta, Microsoft, and PowerSoft have rushed to support both VBXs and OCXs in their language products.
CROSS-REFERENCE
For more on commercial code libraries, see Chapter 31, Chapter 31, and Chapter 15, Chapter 15.
The problems traditionally cited as obstacles to reuse are also being addressed by the free market. For example, companies do not need to create their own repositories of reusable components because VBX vendors do it for them. The vendors' success depends partly on how well they organize, catalogue, and publicize their reuse products so that customers can find the components they need and buy them.
Some people have been puzzled by the success of VBXs, but I think the reason is apparent. VBXs provide for extremely good encapsulation and information hiding, which are the keys to successful reuse. The reuse promised for object-oriented programming languages such as C++ has been compromised by the design of the languages themselves. In C++, for example, the code's developers can develop a class interface that exposes the internal workings of the class. That sabotages information hiding and encapsulation. Or they can use function names that don't give the potential user any idea how to use the class. Because the language doesn't require developers to provide documentation, it can be difficult for someone else to understand a class well enough to reuse it.
When I see a VB custom control, I think, 'There's 1000 hours of my life that I don't have to spend in front of a computer.' | ||
| --Al Corwin | ||
In contrast, the developer of a VBX has no choice but to provide a property sheet, which essentially makes the VBX interface self-documenting. The property sheet completely hides the VBX's implementation, which enforces information hiding and encapsulation. VBXs have succeeded simply because they provide better support for encapsulation than many object-oriented languages do. Modularity and information hiding provide the support for reuse that people want. This finding is consistent with the reports of organizations that have set up their own planned-reuse programs, which I'll discuss later.
Planned Reuse, as the name implies, is a long-term strategy that won't help you on the first project you use it on. In spite of that, no other practice has the capacity to reduce development schedules as much in the long term.
To begin a reuse program, you should first survey your organization's existing software and identify components that occur frequently. You should then plan to make those components reusable over the long-term, either by purchasing them from a reliable vendor or by developing reusable versions yourself.
Reuse links projects that previously could be conducted in isolation, which broadens the scope of decisions about projects. It implies that different projects will have to standardize their software processes, languages, and tools. Effective reuse requires a long-term investment in training and a multi-project plan for building and maintaining reusable components. These are difficult challenges, and virtually every survey of reuse programs or report on a specific program says that management commitment rather than technical prowess is the key to success (Card and Comer 1994, Joos 1994, Jones 1994, Griss and Wosser 1995).
Here are some of the management tasks involved in conducting a reuse program:
Designate a management champion—from top management—for the reuse program. There is no incentive at the first-line-manager level for developing reusable components on a single project, because it makes your project look bad, and there's no incentive for making the next project look good.
Secure a long-term commitment to the program. It's important that reuse not be treated as a fad, since it can take 2 years or more for the development of reusable components to begin to pay off (Jones 1994).
Make reuse an explicit and integral part of the development process. Reuse won't just happen on its own, and it won't happen as a by-product of otherwise good processes. To make its priority clear, make supporting reuse an employee-review level activity.
Convert the organization's software-productivity measurement programs from measuring how much software is developed to measuring how much software is delivered. This will help to ensure that developers receive credit for using reusable components.
Establish a separate reuse group to take charge of the care and feeding of reusable components. In a small organization, the "group" might consist of a single person or even just a part-time person.
Provide training for the reuse group and for the group's potential clients.
Heighten organizational awareness of the reuse initiative through an active public-relations campaign.
Create and maintain a formal list of the people who are reusing components so that they can be notified in the event of problems with the components they're using.
Work out a cost or charge-back system for using components from the reusable components library.
One of the most challenging aspects of setting up a reuse program is that it is difficult to make Reuse succeed without support from other key development practices such as quality assurance and configuration management. Some experts have argued that a reuse program should be implemented as part of a broader process-improvement program (Card and Comer 1994).
CROSS-REFERENCE
Reuse groups have a lot in common with productivitytools groups. For details on those, see Tools group in Productivity-Tool Acquisition.
The group charged with the care and feeding of reusable components will have a lot of work to do. Here are some of its tasks:
Evaluate whether the organization's current software architectures support reuse, and develop architectures that support reuse if needed.
Evaluate whether current coding standards support reuse, and recommend new standards if appropriate.
Create programming-language and interface standards that support reuse. It's nearly impossible to reuse components if they are written in different languages, use completely different function-call interfaces, and use different coding conventions.
Set up processes that support reuse. Recommend that each project start by surveying the components that it might reuse.
Create a formal reusable components library, and provide some means of browsing the library to look for components that might be reused.
Beyond these general tasks, the group will need to do design, implementation, and quality-assurance work on the reusable components themselves.
Focus on domain-specific components. The reuse programs that are the most successful focus on building reusable components for specific application domains. If you're working on financial applications, focus on building reusable financial components. On insurance-quote programs, focus on building reusable insurance components. Try to focus on reuse at the "application domain" or "business component" level (Pfleeger 1994b).
Create small, sharp components. You might be better off focusing your reuse work on the creation of small, sharp, specialized components rather than on large, bulky, general components. Developers who try to create reusable software by creating general components rarely anticipate future users' needs adequately. Future users will look at the large, bulky component, see that it doesn't meet all of their needs, and decide not to use the component at all. "Large and bulky" means "too hard to understand," and that means "too error-prone to use." Data from the NASA Software Engineering Lab suggests that if a component needs to be modified by more than 25 percent, it's as cost-effective to develop a new one-off component as it is to reuse an old one (NASA 1990).
You're better off breaking the large component into several small, sharp components and focusing your reuse efforts on those. In structured-design language, fully factor any component that you intend to reuse. Don't present large components as single, monolithic entities. With smaller, sharper components, you give up the hope of solving the future user's problem in one fell swoop, but that hope is usually unrealistic anyway. With smaller components, you improve the chances of providing at least something of value.
This opinion is somewhat controversial. For a fuller discussion of the RISC vs. CISC debate as it applies to software reuse, see Confessions of a Used Program Salesman (Tracz 1995).
Focus on information hiding and encapsulation. Another key to success is focusing on information hiding and encapsulation—the core of "object-based" design (McGarry, Waligora, and McDermott 1989, Scholtz, et al. 1994, Henry and Faller 1995). Most of the existing, successful reuse projects have used traditional languages such as Ada, C, Cobol, and Fortran (Griss and Wosser 1995). One survey of 29 organizations found that programs developed in languages that are often thought to promote reuse (such as Ada and C++) actually showed no more reuse than those developed in traditional languages (Frakes and Fox 1995).
"Object-oriented" design adds the ideas of inheritance and polymorphism to object-based design, but the addition of those characteristics does not appear to make reuse any more achievable. A panel of researchers and practitioners at the International Conference on Software Engineering in 1994 agreed that object-oriented development by itself was neither necessary nor sufficient for reuse (Pfleeger 1994b). Information hiding and encapsulation are the real keys to success.
Create good documentation. Reuse also requires good documentation. When you create a reusable component, you are not just creating a program; you are creating a product. For it to be used, its level of polish needs to be comparable to products that your organization buys commercially. For that reason, Fred Brooks estimates that developing a reusable component will cost approximately three times as much as developing the same component for stand-alone use (Brooks 1995). Others also estimate that creating components for reuse doubles or triples the cost (Jones 1994, Tracz 1995).
One kind of documentation that's especially valuable for reuse is a list of known limitations for each component. Software is often released with known defects because some bugs are of too low a priority to fix. But a defect that's low priority in one context can become high priority when the component is reused in another product. Don't make people discover defects on their own when you know about them already: document known limitations.
Make reusable components error-free. Successful reuse requires the creation of components that are virtually error-free. If a developer who tries to employ a reusable component finds that it contains defects, the reuse program will quickly lose its shine. A reuse program based on low-quality programs can actually increase the cost of developing software. Instead of paying the original developer to fully debug a component, you pay a developer who is unfamiliar with the component to debug it, probably less efficiently.
CROSS-REFERENCE
For more on the development-speed costs of low quality, see Quality-Assurance Fundamentals, Quality-Assurance Fundamentals.
Focus on the quality of the reusable component library, not size. The sheer amount of code available to be reused does not appear to affect the level of reuse; small code libraries are used at least as heavily as large ones (Pfleeger 1994b, Frakes and Fox 1995). Choosing from a large menu of reusable, existing components can be so difficult that Smalltalk developers refer to the phenomenon as "climbing the Smalltalk mountain." If you want to implement reuse, focus on quality, not quantity.
Don't worry too much about whether developers will accept reuse. Finally, there is less to worry about on the client side of the reuse relationship than people sometimes think. Conventional wisdom holds that developers don't like to use code unless they developed it themselves. But a 1995 survey found that more than 70 percent of developers would actually rather reuse components than develop them from scratch (Frakes and Fox 1995).