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.
Posted by vijaynarayanan 
tempted to make things reusable just in case you need them in another project or application. Pause and reflect at such points because hindsight is 20-20 and you might get better at discerning what is and isn’t reusable over several iterations of a system. There are always going to be assets that don’t fit well together or have neatly packaged interfaces and that is okay!
