How Much Duplication is OK in Software Development?

Every coder worth their salt knows the sacred mantra: DRY - "Do Not Repeat Yourself". It's chanted in nearly every coding guide, textbook, and even by those bearded coding wizards in the corner cubicle. While it's hailed as a cardinal rule, can one ever overdose on such wisdom?

The underlying thought behind DRY is compelling. Let's say you have several "consumers" that all require similar functionality to be implemented. Why build three identical implementations when you can build one and share it? It seems straightforward – avoid duplication to save on both initial development time and future maintenance.

However, like many well-intended guidelines, it's not always that black and white. The potential pitfalls of going too far with DRY ☔ can sometimes be detrimental:

1. Over-Generalization: In an effort to account for every potential use case, we sometimes overcomplicate. Instead of a simple tool tailored for the task, we find ourselves with a behemoth of a system , brimming with features that rarely see the light of day. The time taken to build this 'universal' solution to please all consumers can often far exceed that of creating a simple MVP for each of them separately.

2. Premature Specification: Building the software before understanding the exact needs of the consumers is like putting the cart before the horse. We could end up developing features based on assumed requirements, which may not align with what the consumers truly need.

3. Resistance to Change: A singular, DRY solution has many dependencies. As such, making changes to it can be daunting due to the far-reaching implications of even the smallest tweaks.

So, what’s the middle ground? Here's a revised strategy to tackle this conundrum:

👉 If you have clear and well-defined requirements that warrant a common solution, by all means, go ahead and build it. However, ambiguity should be a sign to start small.

👉 MVP First: Focus on the problem at hand. Instead of anticipating every possible future scenario, concentrate on the present requirements. It's okay to have some duplication if the requirements are still murky. Launching an MVP allows for real-world testing and feedback.

👉 Refactor with Purpose: Once the requirements become clearer or if the burden of maintaining duplicates becomes evident, refactor. This ensures that the solution is always aligned with the current needs rather than hypothetical ones. The rule-of-three serves as a useful guideline in this context.