Reuse pitfalls

1. Underestimating the difficulty of reuse
   • Doing OO development with the explicit goal of reuse is harder and takes longer.
   • Any deficiencies in generality won't show up until reuse is attempted.
   • All the "low hanging fruit" is already provided by the operating system or other environments.
2. Having or setting unrealistic expectations
   • OO development does not guarantee reusable components
   • Even "standard" components routinely require a lot of manual cutting, shaping, fitting, and binding.
   • Objects and subsystems created for one application may have very little relevance for another.
   • Reuse may outstrip the skills and experience of the developers involved.
3. Being too focused on code reuse
   • Design reuse is often neglected in favor of code reuse. The most important creation to come from an OO project is often the architecture and design, not the implementation.
   • Focusing on a "lines of code reused" can be as meaningless and self-defeating as the classic "lines of code" metric.
   • Emphasis on "tangible" classes and code can divert organizational attention from more strategic and abstract framework opportunities.
4. Not investing in reuse
   • Reuse costs effort in analysis, design, implementation, and testing.
   • Reuse may cost additional staff.
   • OO development in general, and reuse in particular, must be supported as a long term investment.
5. Generalizing after the fact
   • "There is never enough time to get it right, there is only enough time to get it done."
   • It is usually easier and faster to write a specific solution than a general one.
   • Generalizing late requires untangling implicit and explicit dependencies that have crept in.
6. Allowing too many connections
   • A complex class may have a dozen of or more other classes to which it refers, each of which will have its own list of dependencies, and so on.
   • Class dependencies should be mapped out during the analysis and design phases and should be tracked as implementation proceeds.
   • You'll probably rearchitext two or three times before you begin in order to get it right.
7. Allowing circular dependencies
   • A circular dependency is one in which you start with a class and trace its dependencies until you get back to that same class.
   • The problem with circular dependencies is not the tight cohesion that will occur within a subsystem, it is dependencies that loop through two or more subsystems.
   • Once more, with feeling: Component reuse must be planned for and designed into a project from the start.