Delay Commitment

The really interesting problems in your domain will require considerable thought, collaboration with project stakeholders, multiple iterations, and real end user feedback. This is the prime real estate for systematic reuse to thrive. However, just because something seems reusable, it may not be…at least, not yet.

Consider these questions….

Is a piece of functionality really reusable beyond the immediate project? Will making something reusable add significant change to the existing design? Is the relevant problem domain for the functionality being understood? how will this functionality evolve over time?

When you have more questions than answers about a potential reusable asset – resist the urge to generalize, add layers of abstraction or product variability. Instead, focus on the immediate business requirement and fulfill just that for your immediate iteration or release. Mark the idea or functionality as a reuse candidate but don’t necessarily make it resuable yet precisely because you may not know what you don’t know.

Kevlin Henney, in an entry in the book, 97 Things Every Software Architect Should Know refers to the this concept calling for ‘Simplicity Before Generality, Use Before Reuse.’ (This book is a must-read by the way – a superb collection.) Additional domain clarity over the life of the project combined with real user feedback will help not hurt your cause.

Additional questions to ask before committing:

• Is this a one-off requirement or part of a recurring theme? Remember – when in doubt, don’t plan for reuse but continuously align and refactor your codebase. Use before reuse!

• Is there a confirmed consumer of this asset beyond the immediate project? If not, keep it in the originating project and promote it for reuse when you find another team or project that needs the functionality

• What are the likely variations that aren’t captured in the existing implementation? are they all really required for day 1, day N ? Don’t implement anything unless there is a business mandate to do so. It is very easy to add code _wishing _someone reuses it rather than refactoring a known good piece of functionality

• Do you have the bandwidth to develop unit tests, capture the right domain abstractions, and write developer facing quick start documentation? If not, resist the urge to prematurely introduce new code that ends up being technical debt