In software, use is better than reuse

If I drink from a plastic bottle of water, and put the bottle in the recycling bin when it is empty, the plastic in the bottle can be used again. This reduces the impact on the environment, but requires a process to collect the bin, sort the contents, process them, and insert any reclaimed materials back into the supply chain.

By contrast, if I drink water from a glass, then I can simply wash it up and put it back in the cupboard. And it is there when I want another drink of water.

This is the difference between reuse and use.

Reuse is a frequently stated goal of technology strategies and architectures. It makes intuitive sense. We spend a lot of money building and buying technology solutions. Different parts of our organisation have similar needs: why not reuse the solutions in more than one place? Some architecture teams even have goals and metrics to measure and encourage reuse. (Like many examples in these articles, this is a mistake that I have made more than once.)

The problem is that these goals are rarely achieved. It turns out that reuse is hard. This CRM system is highly optimised for the needs of one team - and other parts of the business do not even have the same conception of what a customer is. That mobile app is designed for a particular set of users, and a particular style of use - other users find it baffling. And this AI model is trained on data which is interesting and valuable for a single team - but irrelevant to everyone else.

Reusing solutions? such as these requires a lot of work. Configurations must be unwound, new abstractions must be implemented, models must be retrained. This work is the equivalent of creating the recycling infrastructure for my plastic bottle - except that, even if it is successful, it only manages to recycle a single bottle.

Does this mean that we should give up, and simply accept that our technology architectures will be ever more sprawling and complex and that every solution will only ever solve one set of problems for one set of people?

Fortunately, this is not the case, as long as think about use and reuse carefully. Consider a multi-tenant utility such as a cloud platform. Many customers host their applications and data on this platform, but we do not say that they are reusing the platform - we simply say that they are using it. This is because such a platform is designed with use in mind. It has a defined set of APIs, an SDK and a console, it has documentation and training and (if it is well run) it has a product organisation driven by the needs of the platform’s users.

The difference between the mult-tenant cloud platform and the highly optimised CRM deployment (or the specialised mobile app or the contextually relevant AI model) is that they are designed for different things. The goal of the multi-tenant cloud platform is, well, to be used by multiple tenants. The goal of the locally optimised specialist solutions is to be used for the specific purpose they were built for. It is not the case that one type of solution is better for reuse and one type of solution is worse: it is that they have different uses.

I think that the important lesson for architects is that we should not pursue reuse for its own sake, but that we should be clear and explicit about the intended use of all of the components in our architecture. If a component is intended for multiple users, then we should optimise for that mode of use: we should engage with the full user base, we should optimise for ease of consumption. We will probably need to abstract, generalise, and avoid over-optimising for our first use cases. If a component is intended to meet a highly specific need, then we should optimise for the satisfaction of that need - and not lose too much sleep if we don’t find other examples of that need.

Use is better than reuse - as long as we know what the use is.

(Views in this article are my own.)