Build for Use, then Refactor to Reuse

You want to build reusable assets in an agile manner – avoiding a significant design effort upfront and evolving behavior over time.  Why? Because building for reuse involves several steps: the right abstractions have to be identified, appropriate variations have to be modeled and accounted for, and the asset has to be generic enough for use beyond a single project.

This is hard to get right the first time – often, business requirements aren’t clear from the early on making it tricky to identify reusable assets. More importantly, reuse adds project risk – specifically risk to the timeline. Always ask yourself if it is worth making the extra investment – if you aren’t sure delay commitment.

Capture possible enhancements to your codebase via an issue tracking tool and you can always assign those enhancements to future iterations. When you implement a story and you see the opportunity for making something reusable, consciously align classes and interfaces for reuse. Refactor, refactor, and keep refactoring – because only with multiple iterations is your asset going to be increase it’s reuse potential. Remember – very often, the asset would not be used as-is. It will need changes – patches, enhancements, major redesign even – before it can be leveraged across projects.

Advertisements

2 Responses to Build for Use, then Refactor to Reuse

  1. First congratulations for a very interesting blog.
    You may be interested in the “Emergent Reuse” concept proposed by Adam Sroka, in a very interesting thread ( http://tech.groups.yahoo.com/group/extremeprogramming/message/149980 ) that I reuse in my own ( http://acarvalho.tiddlyspace.com/#%5B%5BEmergent%20Reuse%5D%5D ).
    I do agree that some, if not most, of the reuse artefact production shall be performed outside the specific project’s budget but this does not imply that one must abandon Systematic Reuse.
    Refactoring is, in fact, a key point on this.

    • thanks Andre. Reuse carries risk and refactoring components after it is proven in a project or two provides several benefits – the designer won’t overarchitect and imagine features to build and there will be an existing suite of automated tests to leverage as part of harvesting existing code

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: