Reuse Engineering 101

 

Let’s start with some definitions:

• Asset.  An artifact that is retained after its initial purpose is fulfilled.  For example, working source code is an asset because it is retained and potentially updated in the future to address new stakeholder needs.  A user story that is discarded once the functionality it describes is implemented is not considered an asset.
• Robust asset.  An asset that is appropriately documented, generalized beyond the needs of a single team, thoroughly tested, is of high quality, and ideally has several examples to show how to work with it. Robust assets are much more likely to be reused than items without these characteristics.
• Reusable asset.  A robust asset that has been used at least three separate times by at least three separate teams. You can claim that something is reusable, but it isn’t truly reusable until it’s actually been reused; reusability is in the eye of the reuser, not in the eye of the creator.
• Ad-hoc reuse.  An informal approach to reuse where individuals or teams reuse whatever they can find on their own.  Ad-hoc reuse is often a good start.
• Engineered reuse.  A formalized approach to reuse where an organization actively supports a reuse engineering strategy.
• Reuse engineering.   The purposeful creation (or rescue), management, support, and governance of reusable assets.

Why Do We Need Reuse Engineering?

The vast majority of developers, agile or otherwise, take an ad-hoc approach to reuse.  Although this is a good start, we have the opportunity to do much better.  There are several reasons why your organization should consider investing in explicit reuse engineering:

1. Quicker time to market.  The more reusable assets that a team has at its disposal then the less the team will have to build, thereby enabling them to release quicker.
2. Improved return on investment (ROI).  Reuse engineering enables IT delivery teams to avoid building something that your organization already has.  This leads to greater ROI for your IT investment which in turn leads to greater value being delivered to your stakeholders.
3. Improved consistency.  When all of your systems use the same implementation of a service, or component, or function, or framework then that functionality by definition is implemented consistently across those systems.  This makes them more predictable and easier to understand.
4. Easier updates to common functionality.  When functionality is implemented in one place and then reused where needed it is very easy to update that functionality and then deploy the updated version.

Why Reuse Engineering is Difficult

Unfortunately reuse is a lot easier to talk about than it is to implement in practice, at least beyond the ad-hoc level.  There are several reasons why reuse engineering is difficult to achieve:

1. There is a greater impact when reusable assets break.  When an asset is used in only one place and it breaks, then the impact of that breakage is limited to that one place.  When an asset is reused in dozens or hundreds of places, and it breaks, then the impact is significantly larger.  This is reusable assets need to be of high quality.
2. Teams must go beyond the reuse of source code.  Reuse is often described as not “reinventing the wheel,” and an important step for succeeding at reuse is to understand that you have more than one option at your disposal.  For example, in addition to source code you can reuse components, services, patterns, and templates to name a few.  More on this in a future post.
3. Reuse requires enterprise awareness on IT delivery teams.  For reuse to succeed IT delivery teams must understand that reusable assets exist, how these assets fit into your overall IT ecosystem, and what the benefits of reusing them are for your organization.  In Disciplined Agile we promote the philosophy that IT delivery teams should work closely with enterprise architects and reuse engineers, if any exist, so that they will better understand and appreciate these issues.
4. Reuse requires investment.  To get beyond ad-hoc reuse your organization will need to invest in a reuse program.  This may include investment in a reuse engineering team, in a reuse repository, in the development/rescue of potentially reusable assets, and the long-term maintenance and support of those assets.  More on these topics in future postings.
5. Your approach to funding will make or break reuse.  Many organizations will institute chargeback schemes to pay for reuse.  The basic strategy is that just like you would pay for commercial software, you should pay for internally developed or purchased assets within your organization.  That way the cost of those assets is shared fairly across the teams that are actually reusing them.  Unfortunately, in practice, chargeback schemes are guaranteed to kill your reuse engineering efforts because you are in effect punishing teams when they reuse things.  A better strategy is to purposefully fund your reuse engineering efforts and then track, often via automated metrics, the impact those efforts have on your organization (so as to justify the investment).

In future blog postings we will explore a goal-driven approach to reuse engineering as well as the workflows associated with reuse engineering.  It is possible, and highly desirable, for organizations to succeed at reuse engineering.  The Disciplined Agile Reuse Engineering process blade provides the guidance you need to do so.