Once You Start Copying.

There is a related lesson we have told elsewhere: that duplication stays cheap until the copies have to change together — and that the mistake was missing that tipping point. This story looks at the same material from the other side. Not the moment copying became expensive, but the slope that led there. It is deliberately kept general — no system, no people involved, no date.

Situation

In an existing system, one piece of functionality existed not once but dozens of times. The same task had been solved in many places, each copy adapted slightly to its location, none quite like the other. Altogether, around 5,000 lines of nearly identical code had accumulated this way, spread across the entire system.

Initial assumptions

The first copy was not carelessness but a defensible, local decision. When the task came up a second time, the shared shape was not yet clear, and a speculative abstraction would have been a bet — possibly the wrong one, which costs more than any copy. Copying was fast, independent and safe. That assumption was right for the first copy. The unspoken part was the assumption that what was right once would stay right the next time, and the time after that.

Problem

Over time, the codebase became extremely hard to maintain. Whenever the shared rule had to change, it had to be changed in many copies at once — and you could never be sure you had found them all. A fix in one place didn't reach the others; the same task behaved differently depending on the copy. The deeper finding lay underneath: nobody had ever decided to have dozens of copies. Each one was defensible on its own; their sum was not. The cost did not arrive with any particular copy — it accumulated below the threshold at which someone would have paused.

Root cause

The real cause was the momentum of copying. The first copy lowers the bar for the second; the second makes the third a matter of course. Every occurrence makes the next one seem more natural and less worth examining. The mistake lay not in any single copy but in the missing decision point after the first. Duplication grows so quietly precisely because each step is small and justifiable on its own — the danger is the slope, not the first step.

Decision

Batunet decided to replace the duplicated implementation with a clean solution — not because copying is forbidden, but because the copies, through their number and their shared drift, had shown that they were a single thing in many disguises. The shared shape that could only have been guessed earlier was now visible. That made the abstraction no longer a bet but something backed by evidence.

Implementation

The refactoring did not happen in one leap but in small, reversible steps. First, the actual commonality was carved out — what all copies genuinely shared, separated from what merely happened to look the same. That commonality was expressed exactly once, behind a clear boundary. Then the copies were switched over one by one, each with the goal of leaving behavior unchanged before anything was improved. In the end, the code was about 90 percent smaller — the same capability, in one place instead of many.

Trade-offs

Consolidation is neither free nor always right. The single solution now has to be maintained; it concentrates what used to be scattered and makes that one place important. The price of the early copies — the waiting — was the deliberate trade-off for not building the wrong abstraction. We would have decided differently if the copies had genuinely stayed independent: then merging them would have been a mistake, coupling what belongs apart. Two occurrences may remain a coincidence; the point is not to overlook the third.

What we learned

The dangerous moment is not the first copy but the second — the instant when copying stops being a choice and starts becoming a habit. The rule we took away from this is old and simple: two similar occurrences can be coincidence; the third is a pattern and a decision point. "Don't Repeat Yourself" says that knowledge that changes together should be represented once; the Rule of Three says when to act. The lesson is not "never copy" — it is "never copy unconsciously."

How this changed Batunet

Since then, we make the second occurrence visible. When a copy shows up in review, we deliberately ask: is this the second? The third? We copy without a guilty conscience as long as the copies are independent, and we treat the third similar occurrence as the moment to merge. Copying is allowed; copying without a decision is not. A silent slope has become a point where we deliberately pause.

Further reading

• Guide: Software That Still Runs in Ten Years — why coupling and changeability decide over a system's lifetime.
• Decision: The Modular Monolith as a Starting Point — add structure when a problem demands it, not before.
• Playbook: Modernizing a Legacy Monolith — consolidating in small, reversible steps.
• Opinion: Why Premature Abstraction Creates Complexity — the wrong abstraction costs more than duplication.
• Glossary: Rule of Three — merge on the third occurrence, not the first.

No copy comes from a decision to have dozens. They come from many small steps, each reasonable on its own — which is why the second one has to be taken as deliberately as the first.