Be Demand Driven

Most software assets don’t start out reusable unless a big design effort is spent upfront. There is a piece of functionality that needs to be created and during the first few iterations it might mature into something reusable. Instead of committing to developing software assets to be reusable immediately evolve them through a simple lifecycle. If you suspect something is reusable mark it down as a reusable candidate. Don’t commit right away. Isolate the component, module, or service as much as possible from the rest of the product but don’t spend significant effort yet. Once the functionality is better understood you can always refactor this into a full fledged reusable asset. This also would have the advantage that the reusable asset for sure will have a consumer (the app that was using the candidate version of this functionality!).

_What do you do if you have a candidate and there is another app that needs the same functionality?_In such cases provide the new consumer with a refactored and reusable API. Let the new application use the reusable API and in a subsequent iteration switch the candidate code to the reusable API for your original application. This has the advantage of not breaking your original application as well as providing a migration path to align all consumers to a single asset.

I typically mark an asset as a potential for reuse to start with and then when the asset gets refactored it becomes a reuse candidate. Finally, when it gets integrated with a consumer it becomes a reusable asset. The important thing to note is that at any given time your application might have several assets in varying stages of evolution. Not all of them might need refactoring at the same time. You pick what you want to refactor and make reusable based on demand (how many apps or products need the functionality?) and priority (is it high priority for your business sponsor? if not, does demand warrant justification of committing resources to make the necessary changes?).