Reuse remains one of the holy grails in software architecture. How wonderful is life if we can write a piece of code(component, module, service, you name it...) only once and then start to use it everywhere?
It is not surprising that I see a lot of IT managers and architects always play the 'reusability' card no matter the context. Reusability is important. Period!
The risks of reusability
As a consequence hours and hours are spend in meetings, design discussions, alignment sessions between stakeholders… to find out how we can make what we are trying to build reusable. This not only overcomplicates our designs but can also lead to gold plating(“What if this happens?”, “Maybe we will need that somewhere in the future?”).
Another effect of this unhealthy addication to reuse is that it starts to hinder usability. By building a UI component, a piece of code or a data model in such a way that it becomes re-usable, it also becomes more ‘generic’ or ‘general purpose.
My youngest son is learning to write. Yes, he can use a blank sheet of paper to write his first words, but a purpose built paper with preprinted lines makes it a lot easier for him to write.
Although a blank sheet of paper is reusable in a lot more situations, it makes his job; writing his first words; a lot harder.
Therefore:
Before something becomes re-useable, it must first be useable.
And that can only be achieved when it is built for purpose.
Reuse is a fallacy
The core idea behind reuse is to get things done faster. We believe that by creating something reusable we can build our IT solutions faster.
One of the reasons we fall in this trap, is that we confuse reusability with standardization. Standardized parts support building something at a lower price and can easily be reused in multiple products. By investing extra time up front while designing a part, we can save time and money in the long run because we can make as many copies as we want, without having to pay extra.
Although this is certainly applicable in the real world, it is far less the case in software development. In software development, we can prototype a lot faster. The cost of designing a component is really small compared to designing physical products.
The hidden cost of reuse
A situation I have seen a lot at customers is that first a large amount of time is spend in designing a component in such a way that it should be reusable. (Notice the should be, because at the moment we have designed the component, we have not implemented it anywhere so we have no idea if we can achieve our dream of reusability).
This component is then provided to a development team that tries to use it, has to spend time to understand how it works, if it can tackle their needs, if changes are needed and so on. As a result, each party that tries to use that asset, needs to spend extra time, costs and efforts to understand how the asset works, if it can handle their context, if they need to change it to make it work, to test it and so on. In other words: Each user of the “reusable” asset has to make the asset usable for their context.
Worst case this can cost more than writing a solution for the given context from scratch.