What can you reuse on agile software teams?

 

An important philosophy for succeeding at reuse engineering in the information technology (IT) space is to understand that you have more than one option at your disposal.  You can reuse source code, components, development artifacts, patterns, and templates.   The following diagram summarizes the types, or categories, of reuse available to you.  The left-hand arrow indicates the relative effectiveness of each category – pattern reuse is generally more productive than artifact and framework reuse for example.  Similarly, the right hand arrow indicates the relative difficulty of succeeding at each type of reuse.  Code and template reuse are relatively easy to achieve because you simply need to find the asset and work with it.  Other forms of reuse become hard to achieve; with framework reuse you need to learn the toolkits, with pattern reuse you must learn when to (and when not to) apply various patterns, and with architected reuse you need an effective approach to enterprise architecture in place.

The reuse categories are:

• Architected Reuse.  The identification, development, and support of large-scale, reusable assets via enterprise architecture.  Your enterprise architecture may define reusable domain components, collections of related domain/business classes that work together to support a cohesive set of responsibilities, or service domains which bundle a cohesive collection of services together.
• Pattern Reuse. The use of documented approaches to solving common problems within a specified context.  With pattern reuse you’re not reusing code, instead you are reusing the thinking that goes behind the code.  Patterns can be a multiple levels – analysis, design, and architecture are the most common.  Ward Cunningham’s site is a useful source of patterns on the web.
• Framework Reuse. The use of collections of classes that together implement the basic functionality of a common technical or business domain.  Horizontal frameworks, such as a security framework or user interface frameworks such as the Kendo or QuickUI.   Vertical frameworks, such as a financial services framework, are common in some domains.
• Artifact Reuse. The use of previously created development artifacts – use cases, standards documents, domain-specific models, procedures and guidelines, and even other applications such as a commercial off the shelf (COTS) package – to give you a kick start on a new project.  Sometimes you take the artifact as is and other times you simply use it as an example to give you an idea about how to proceed.
• Component Reuse.  The use of pre-built, fully encapsulated “components” in the development of your solution. In this case a component is self sufficient and encapsulates only one concept.  Component reuse differs from code reuse in that developers don’t have access to the source code.
• Template Reuse. This is the practice of using a common set of layouts for development artifacts such as vision documents, training slide decks, or system overview wiki pages within your organization.
• Code Reuse. The reuse of source code within sections of an application and potentially across multiple applications.  At its best code reuse is accomplished through the sharing of common classes and/or collections of functions and procedures.  At its worst code reuse is accomplished by copying, pasting, and then modifying existing code which adds to your organization’s technical debt and can potentially result in negative overall value.

You can address these reuse categories simultaneously.  Framework reuse often locks you into the architecture of that framework, as well as the standards and guidelines used by the toolkit, but you can still take advantages of the other approaches to reuse in combination with framework reuse.  Artifact and component reuse are the easiest places to start, with a little bit of research you can find reusable items quickly.  However, if your organization doesn’t have a common development process that it follows you may get little benefit from templates.  Pattern reuse is typically the domain of developers with good modeling skills and your enterprise architects should be publishing and providing pattern-oriented guidance to them.

It is important to note that although the diagram indicates that pattern reuse is generally more effective than artifact reuse you may discover that within your organization the opposite holds true.  This may occur because you have a comprehensive collection of reusable artifacts in place, because your organization culture is conducive to artifact reuse, or simply because your developers have little experience with patterns.