Reuse Is About People and Education, Not Just Architecture
Jeremy Meyer
you MigHT AdopT THE AppRoACH that a framework that is well designed, or an architecture that is carefully considered and cleverly implemented, will lend itself to reuse within your organization. The truth is that even the most beautiful, elegant, and reusable architecture, framework, or system will only be reused by people who:
Know it’s There
Within your organization, developers or designers need to know that a design, framework, library, or fragment of code exists, and where they can find all the critical information about these elements (e.g., documentation, versions, and compatibility) in order to reuse them. It is a simple, logical truth that people won’t look for things that they don’t believe exist. You are more likely to suc- ceed with reusable elements if the information about them is “pushed.”
There are any number of methods for pushing information about reusable elements in an organization. These range from wiki pages with an RSS feed providing update information, useful in very large teams, to email announcing version updates in the source repository. In a tiny team, the designer or lead developer can inform his colleagues in personal conversations or by shouting it across the office. Ultimately, whatever your process for communicating about reusable elements, make sure you have one—don’t leave it up to chance.
Know How to use it
Understanding how to reuse an element depends on skills and training. Of course there are those people who (to use Donald Knuth’s terminology) “reso- nate” with coding and design. We have all worked with them, the gifted devel- opers and architects whose speed and depth of understanding is impressive,
52 97 Things Every Software Architect Should Know

even scary. But these people are rare. The rest of your team might be made up of good, solid, intelligent developers and designers. They need to be taught.
Developers and designers might not know of the particular design pattern used in a design, or fully understand the inheritance model that the frame- work designer intended them to use. They need to be given easy access to that information in the form of up-to-date documentation, or even better, training. A little training goes a long way toward ensuring that everyone is on the same page when it comes to reuse.
Are Convinced That it’s Better Than doing it Themselves
People, and particularly developers, tend to prefer to solve problems themselves rather than ask for help. Asking how something works is a sign of weakness, or even an indication of ignorance. This has a lot to do with the maturity and personality type of your individual team members; “better than doing it them- selves” means different things to different people. The “young guns” on your team will always want to write things themselves because it appeases their egos, whereas your more experienced people are more likely to accept that someone else has given thought to the problem domain and has something to offer in terms of a solution.
If your team doesn’t know where to find reusable artifacts or how to reuse them, they will default to the natural, human position: they will build it them- selves. And you will pay for it.
Jeremy Meyer has been designing and developing software for nearly 20 years, as well as teaching its mastery. He is currently a principal consultant for Borland Software in its modeling and design space.