Duplicated Code

What duplicated code is and why it matters

Duplicated code is repeated logic in more than one place, whether the copies are identical or only similar enough to behave like the same idea expressed twice. That repetition is often introduced for speed, but it creates a long-term maintenance burden because a bug fix, rule change, or security improvement has to be applied everywhere the logic appears.

The practical problem is not just extra lines of code. Duplication weakens consistency, because each copy can drift as teams update one fragment but miss another. Over time, that drift makes the codebase harder to reason about, harder to test, and more likely to produce uneven behaviour in production.

How duplication develops in real codebases

Duplication usually appears when teams copy a working pattern to avoid re-implementing it, when deadlines reward reuse by paste rather than abstraction, or when similar logic evolves in parallel across files, services, or product areas. It is common in business rules, validation logic, formatting, error handling, and access checks, where the same rule feels small enough to replicate.

Not every repeated pattern is automatically a defect. Some duplication is intentional and harmless, especially when the repeated code is simple, stable, or easier to read than an abstraction. The key question is whether the copies are likely to change together. If they are, duplication becomes a design and maintenance liability.

Why duplicated code creates security and quality risk

Duplicated code raises the chance of inconsistent fixes, which is a security problem when the repeated logic governs validation, authorization, sanitisation, logging, or error handling. If one copy is corrected and another is left behind, an attacker may look for the weakest path, while defenders may believe the issue has been fully addressed.

It also increases the surface for regression. A safe change in one location can be undone by a later edit in a forgotten duplicate, or two copies can diverge so that they no longer enforce the same business rule. In larger systems, that creates subtle trust gaps between components that appear equivalent but no longer behave equivalently.

How engineers reduce duplication without over-abstracting

The right response is usually to remove duplicated logic only when the repetition represents a single underlying rule or mechanism. Shared functions, libraries, modules, configuration, or policy-driven controls can improve consistency when they truly centralise the behaviour that should not vary.

Good refactoring is selective. Over-abstracting small or unstable code can make a system harder to understand than the duplication it replaced. The better standard is to consolidate code when a single source of truth is clearly needed, but keep separate copies when the differences are real and will likely remain that way.

One useful rule is to treat duplication as a signal to review design, not as an automatic mandate to merge code. The aim is predictable behaviour, simpler change management, and fewer places for defects or security mistakes to hide.

How teams should manage duplicated code over time

Duplicated code is best handled as a maintainability control: identify where repeated logic is business-critical, track whether copies are still aligned, and review whether future changes would need coordinated updates. In practice, the most important duplicates are the ones that affect security decisions, data handling, or core user flows.

Why practitioners should care: Duplication is often acceptable in the short term, but it becomes expensive when the same logic must be fixed, tested, and audited in multiple places. Teams should pay special attention to repeated code that encodes rules rather than presentation, because that is where drift causes the most harm.

Practitioner takeaway: If two fragments are expected to evolve together, prefer a single well-owned implementation. If they are only superficially similar, keep the duplication only when it improves clarity more than abstraction would.

Related resources from NHI Mgmt Group

• How should engineering teams reduce duplicated code without creating fragile abstractions?
• Why does duplicated code increase long-term delivery risk in large codebases?
• Why is hardcoding credentials into source code so dangerous?
• What is the difference between code scanning and runtime identity monitoring?