Object Reuse Within the Enterprise: A Report From the Field


Code reuse and especially object reuse is not a new topic.  Software professionals have been talking about reuse for decades, but somehow true reuse still eludes virtually every organization engaged in software development.  Scanning through the literature on reuse one can find plenty of articles on the benefits of reuse and even quite a few sources on object oriented design principles that best lead to reuse.  What is missing, are success stories and practical advice on how to make reuse a reality within your organization.  That’s where this article differs.

This article is based on first hand experiences implementing reuse practices and strategies at companies such as Alamo Local Market Division and FedEx Custom Critical. We will start by exploring what we actually mean by reuse.  Next we will provide a reuse practices maturity model that you can use to gauge progress within your own organization. We will conclude with an overview of the specific practices and tools that we’ve used to implement reuse practices and strategies.

What is Reuse?
Almost everyone I talk to has a different idea about what constitutes reuse.  For example, if a developer copies a source file from one project into another project, is that reuse?  How about if the developer copies a compiled class instead of a source file?  My point is not to state that one view is correct and the other isn’t, but merely to point out that there are many kinds of reuse.  And if we are going to make any true headway in the practice of reuse we have to understand these different kinds of reuse and the repercussions of each.  To this aim I would like to suggest the following Reuse maturity Model.

Reuse Maturity Model
The following Reuse Maturity Model is based on experience within my software development organization as well as experiences with and observations of other development organizations.

Level 1 - Single Project Source Based Reuse Organizations at the first maturity level place all their source code within a single project. Very often this single pool of source code will hold multiple applications. Project A is home to two applications: A and B. This practice totally sidesteps the above question of whether copying a source file from one project to another project constitutes reuse. There is simply no need to copy source files or compiled files from one project to another because there is only one project.

Of course, there is a limit to how well this practice will scale. Once the number of applications or the number of developers increases, maintaining a common pool of source code will become increasingly difficult.

Level 2 - Multi Project Source Based Reuse The next stage on the reuse maturity roadmap is to separate the source base into multiple projects (usually the project boundaries will correspond with the application boundaries) and practice source based reuse between the projects. Source based reuse in this scenario entails copying the source developed in one project into another project. The prime targets of such reuse are utilities, which were originally developed in one project but can be used in the next project. Project A is home to application A and project B is home to application B. The code common to both projects (depicted in orange) is copied into both projects.

The problem with multiple project source based reuse is that after being copied, the reused source code has no link back to the original. This causes all sorts of maintenance problems, since bug fixes will have to be applied to every project that reuses the copied code (something that will never happen in practice).  Also, as the two host project evolve, the reused code will evolve with them, thus making maintenance even more difficult.

Level 3 - Ad hoc Binary Reuse Ad hoc binary reuse is the next step along this maturity roadmap. Organizations advance to this level after trying multi-project source based reuse and realizing the drawbacks of that approach. Under ad hoc binary reuse, project boundaries realign and no longer mirror application boundaries. Projects at this maturity level can correspond to applications or to reusable components. The utilities source code



About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.