Design for Emergent Reuse
Design for well-defined use cases and adaptability. Address reuse as an optimisation opportunity rather than a goal.
Rationale
This principle is a version of YAGNI applied specifically to reusability rather than functional features. We believe it deserves extra attention in this context as it can conflict with our natural instincts about what good looks like.
Designing for reuse from the outset, in the absence of well-understood use cases, requires us to make assumptions about what will be valuable at some point in the future. These assumptions usually turn out to be wrong. As well as wasting effort and creating a cost of delay, we have seen this approach to reuse significantly inhibit change, by creating unnecessary complexity, dependencies and bottlenecks.
Code that is designed for reuse is generally harder to build, maintain and use than code designed for a single purpose1, so we should first establish that there is concrete value in reuse outweighing the costs, and accept duplication until then.
Implications
- Identify reuse as it emerges through evolution or modelling the business domain; prefer duplication over premature abstraction until you have evidence new dependencies will not constrain the required pace of change.
- Be sceptical of components that look similar but aren’t the same once you consider business use cases and what might trigger them to change and diverge.
- This principle will require particular attention when considering core capabilities with the potential to serve multiple brands or channels.
- This principle can only be effective if reuse can be enabled in the future at a similar cost to today. We must therefore focus on building easy-to-change Evolutionary Systems.
- If reused code becomes a bottleneck, remove the coupling by forking or duplicating the code.
- The risks of reuse are usually lower for generic, domain-independent features such as monitoring, logging, service discovery, configuration, etc. The opportunities and risks of patterns such as Service Templates and Service Chassis should be evaluated in this context, aligned with our approach to technological diversity described in Keep Pace with Technological Change.