Understand Lack of Reuse

Some software assets don’t get reused – question is – is the reason well known? if so, what is being done to ensure that it doesn’t happen too often? In agile methodology, the retrospective serves as a vehicle to reflect on the iteration. Reflecting on the experience overall – what worked, what didn’t work, how can the team improve and so on.

In the same token, consider retrospective for reusable assets – did the asset get used the way it was intended to be used? if not, are new use cases providing opportunities that weren’t considered earlier? In the rush to perfection, there is always a danger is adding too much complexity to an asset. Are consumers even using all that complexity? remember there is a cost to complexity – having the right level of complexity with multiple instances of reuse is a happier place to be.

When you work with the internal development team and asset consumers – ask them specifically why something isn’t working. Is it the lack of adequate documentation and/or code samples? does the asset fail because it didn’t have domain relevance? are there better (cheaper, faster, more maintainable) ways to achieve the asset’s functional objectives? is it too slow and doesn’t meet performance SLA needs? are there too many configuration options? doesn’t work well in a particular runtime environment?

You get the idea: there are specific reasons why your software asset isn’t being reused. Find out why – continuously refactor and resolve root causes to get a higher return on your software investments.