Reuse programs that fail to ``get off the ground'' frequently share the problem that the incentives to produce and utilize reusable components are lacking or subverted. For example, when project managers are held accountable for increased costs and project delays, they tend to avoid reuse investments. In such an environment, an edict to produce reusable components is not likely to be very effective since it conflicts with project's cost/schedule performance. Other ``knee-jerk'' responses to the symptoms of reuse inhibitors may be misaligned with reuse goals. For instance, cash bonuses for component deposition may give rise to a large but worthless library. This is not to say that cash bonuses are necessarily bad, but that unless the overall picture is considered, the attempted ``solution'' may have undesirable consequences.
It is generally recognized that attempting to eliminate a symptom rarely solves the root problem, yet this is precisely what we often observe in the case of reuse. To be fair, high pressure, tight development cycles make it hard to distinguish problems from symptoms. It is, therefore, important to invest in up-front analysis to develop a systemic understanding of the software development organization, it's goals, processes, people, opportunities and challenges. Armed with this self-knowledge, the organization is better able to create an integrated solution to the problem of achieving levels of reuse that are aligned with it's overall objectives.