Reuse programs generally improve quality and productivity and lower cost. At the project level, reuse tends to reduce risk because less of the product needs to be hand-coded, and the quality of reused components is generally higher than that of one-off components. At the organization level, however, a family of risks clusters around the difficulty of predicting which components will need to be reused.

Wasted effort. Creation of reusable components costs two to three times as much as creation of a one-off component. Once the component is developed, you have to use it at least two or three times just to break even. Ted Biggerstaff calls this the "Rule of Three": before you receive any benefit from reusing a component, you have to reuse it three times (Tracz 1995). If you're not sure that you will reuse a component at least three times, it might still make sense to have prebuilt components available from a future-development-speed point of view, but that speed will come at a price.

Misdirected effort. If you establish a separate group to develop reusable components, there is a chance that the group will develop components that are never used. If the reuse group guesses wrong and one out of four of its components are never used, you would have to plan to use each component that you do reuse at least five times just to break even. Within a single organization that doesn't develop an awful lot of really similar systems, that can be a difficult break-even point to meet.

A practical strategy that reduces this risk might be to implement a "Rule of Two": implement every component as a one-off component the first time—and then, the second time it's needed, consider making it reusable. At that point, you know that you're going to be using it at least twice, so you are implicitly accepting less risk if you believe that some reuse now implies more reuse later. But be careful. Some experts warn that if you have not yet built three real systems in a particular domain, you probably don't yet know enough about it to create reusable components successfully (Tracz 1995).

Shifting technology. A risk of Planned Reuse arises from the fact that it's a long-term strategy. Not only do you need to use a component several times to break even, you need to use it before the bottom drops out of the technology it's based on. As Chris Peters says, "You can spend so much time making something sharable, only to have it be obsolete two years later. In a world where things change so fast and so furiously, you tell me what part ought to be shared" (Peters in Cusumano and Selby 1995).

Overestimated savings. Don't assume that reusing code will produce large time savings. If you reuse only code, you'll mostly save only coding time. If you reuse other project artifacts, you can save other time too.

Keep in mind that it costs something to reuse a component because of the time needed to find that component and to learn how to use it. Plan to spend about one-fifth as much to reuse a line of code as to develop it from scratch (Tracz 1995).