Common wisdom dictates that we should reuse as much as possible, but in practice we never seem to achieve this goal. Why? We could blame the not-invented-here syndrome—the belief that because a developer didn't create something, he or she will refuse to reuse it—but this is specious: Most developers are practical and will readily reuse any high-quality items applicable to their current situation. The secret to increasing reuse within your organization is to identify and adopt the appropriate development techniques that create recycling opportunities.
Principles of Reuse
Organizations that are successful at reuse share several common philosophies. First, they recognize that you can reuse more than just code. Components, frameworks, documentation templates, software processes and development standards can all be reused—and that's just the tip of the iceberg. Second, something isn't reusable until it's been reused. In other words, reuse is in the eye of the beholder—not the creator. Third, reuse is a mindset. To increase the level of reuse within your organization, individual developers must actively strive to reuse the wheel rather than reinvent it. Fourth, successful organizations differentiate between project-level reuse and organization-level reuse because they recognize that they require different approaches. Project-level reuse is easier to achieve because it's localized to a single team, whereas organization-level reuse can have a greater impact on productivity, but is much harder to achieve due to its greater complexity.
Strategies for Project-Level Reuse
There are three general approaches to project-level reuse: grass roots, planned and external source (see table). In grass-roots reuse, sometimes called accidental reuse, a developer builds something on one project and then adapts it as needed on the next project. This approach is common and successful, because developers tend to work with similar technologies (albeit occasionally newer versions) within the same domain. As a result, it's easy to modify previous work to fit a new project.
A second approach, planned reuse, or reuse-by-design, is often attempted, but is seldom successful. With this approach, you design an item from the start with reusability in mind, striving to make it sufficiently robust, so it's attractive to other developers. This effort often entails identifying requirements not directly applicable to your current project, including potential future requirements for your project as well as requirements for other development efforts, and then acting on those requirements. In other words, you overbuild the item and hope that you guessed right.
The third approach to project-level reuse is external-source reuse, which employs reusable items from outside your project. Commercially available components and frameworks are likely reuse candidates, as are free items downloaded from the Internet, including the wealth of open-source software code. Or perhaps a friend on another project within your organization provides an item that you examine, try and then modify for your needs.
Project-Level Success?
Grass-roots reuse works particularly well for project teams taking an agile approach to software development, particularly methodologies such as Extreme Programming (XP) and Agile Modeling (AM), which focus explicitly on quality work. If your process demands the creation of high-quality artifacts, you dramatically increase the chance that they'll be reuse candidates. Furthermore, if you've invested the minimum amount of resources to build an item—agile software development generally doesn't support overbuilding—you're more likely to invest additional resources to extend the item to meet your new needs because you haven't already maxed out your entire budget.
Planned reuse works best with a prescriptive process such as the Rational Unified Process (RUP), because it supports the process framework with-in which you can tailor reuse design procedures. Note that there isn't anything inherent in the RUP that increases your chances of success: You'll still need good people who get lucky predicting what will be required.
An external-source approach is often effective with both agile and prescriptive software processes-agile developers will often actively seek to reuse items such as (MySQL) or (OpenORM), and prescriptive processes can easily include steps to look for reusable items before building them.
Strategies for Organization-Level Reuse
Organization-level reuse focuses on systematic reuse across your organization's portfolio of software projects, a task often referred to as reuse management. This type of reuse can be difficult because it requires processes and organizational structures within your IT department that are beyond the scope of a single project—organizations that are struggling to deliver individual projects typically don't have the wherewithal to succeed at organization-level reuse. If you believe you do, consider three basic approaches—harvested reuse during development, harvested reuse after development and institutionalized reuse-all of which are compared above.
With the harvested reuse approach, your organization has a team of reuse engineers who rescue items from projects, rework them to be potentially reusable and then place them in a reuse repository to make them available to all developers. Usually, the engineers wait until a project concludes before performing a reuse assessment of the work performed, harvesting candidate items only after they've been baselined for production. During the reuse assessment, identifying an item's potential customers is a crucial consideration. However, remember not to count your chickens: They aren't actual customers until they actively reuse your item.
You can also harvest items during development. You'll either require the project team to identify potentially reusable items themselves, or have reuse engineers occasionally review project efforts. Once an item has been earmarked as a reuse candidate, your reuse engineers will rework it in parallel to the project team's efforts, eventually helping the project team replace the original item with the new and improved reusable version.
Following an institutionalized reuse approach requires explicit software processes that promote reuse within your organization, managing reuse across several projects. This may include a top-down approach to enterprise requirements and architectural modeling ("Architectural Modeling: Part 1 and 2," Thinking Objectively, Sept. and Oct. 1999), specific infrastructure projects based on your architecture models and even internal open-source projects ("Reuse Through Internal Open Source," Thinking Objectively, Dec. 2000).
When Does Organization-Level Reuse Work?
Harvesting items in parallel to development works reasonably well in agile environments, particularly when development teams follow public ownership practices that allow anyone on the team to work on project artifacts—it isn't that big a stretch for development teams to give access to corporate reuse engineers, particularly when the teams share good rapport. Harvesting items after the fact goes against the grain of most agile developers, particularly if an actual customer for the item hasn't been identified (potential customers don't count). However, organizations following prescriptive processes may find this risk acceptable, particularly when an item has several high-probability potential customers. Institutionalized reuse is more likely to be attempted by organizations following prescriptive software processes, although those processes need to explicitly include cross-project activities. At present, the RUP doesn't include such activities, although the OPEN process and the Enterprise Unified Process (EUP) do.
Reuse Is Possible
You can succeed at increasing the level of reuse within your organization. First, you must foster a reuse-positive mindset; second, recognize that there are multiple approaches to achieving reuse; and third, choose one or more approaches that fit best in your environment. Reuse is far easier said than done, but it's worth the effort to reap the beneficial repercussions of a project's success.
|
Comparing Reuse Strategies
|
