Getting Started With Reuse By Harvesting Existing Code

August 23, 2012

Many teams want to incrementally build a portfolio of reusable components so multiple projects can leverage them. This post will provide a list of potential areas to look for achieving systematic reuse – chances are that you have a few components in these areas already. Assembling them into a standard set and making it available for easy consumption will dramatically increase adoption rates across projects. Here are the areas to invest and/or harvest existing code:

  • Configuration – specifically properties that vary across environments (e.g. DEV, QA, PROD). How are teams defining and managing this information today? If you are using Maven,  teams may be employing multiple strategies – profiles, assemblies, custom scripts, naming conventions, etc.  Why not consolidate practices?
  • Transformation APIs – many projects require data transformation between objects to JSON or objects to XML and vice versa. Teams might be using different transformation libraries, may be wiring them with Spring or other dependency injection frameworks in a bespoke manner. Why not adopt a consistent API that provides transformations via a common set of classes with pluggable format-specific providers?
  • Flexible Query Construction – lookup methods that require one or more parameters will end up having common boiler plate code that binds parameters using boolean conditions – why not provide a reusable API that allows the developer to wire parameters using a common API?
  • Integration with internal and/or external systems – retrying, alerting, message construction, metrics, and proactive monitoring are all cross cutting concerns that are common across projects. Teams must be realizing these capabilities using multiple APIs, injection hooks, and response loops – again a consistent and reusable API will not only cut development costs but also make application support simpler

Existing code and components do however carry several risks that have to be addressed to realize reuse potential. For example:

  1. How domain agnostic are the components? Does it have a well defined interface and ability to adapt to a family of use cases?
  2. What is the learning curve for developer adoption? Does it have well defined adoption patterns that are easy to learn and intuitive?
  3. How testable is the component? Does it have interfaces that capture and model varying behavior ?
  4. What is the support model for the component? How to submit bug fix or enhancement requests? is there enough expertise in the developer community?
  5. What will be the release cycle for reusable components ? This becomes critical as more projects start to leverage a common suite of components for a varying set of capabilities

In a hurry to decide if something is reusable?

August 15, 2010

I have heard some variation of the following line from developers, technical leads, and architects – “we want to make things more reusable, but we don’t have the time.”

There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:

  • is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
  • is the capability making something incredibly hard/defect prone simpler and/or easier?
  • is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
  • is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
  • is the capability only available in a particular technical platform but is solving  an often needed problem?
  • is it automating boiler plate code generation or preventing defects?
  • is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.

This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.


%d bloggers like this: