When to repeat yourself

DRY (Don't Repeat Yourself) is a foundational principle, but removing duplication always has a cost. Across team or service boundaries, the coordination overhead of shared components can outweigh the maintenance burden of duplicated code. Two pieces of code that look identical may represent different business concepts (incidental vs. inherent duplication) and should be left separate. When sharing code across services, a shared library introduces language and dependency coupling, while a microservice adds network latency and operational overhead. Inside a codebase, inheritance creates rigid coupling that breaks down when subclasses need to diverge, while composition offers flexibility at the cost of complexity. The key insight: merging duplicated code later is easy, but splitting a shared abstraction with many callers is hard. When in doubt, let the duplication live until the right abstraction emerges from real evidence.