Don't Repeat Yourself

Copying is always the fastest route while you are building. Working code is sitting right there, so writing it again from scratch makes no sense; paste it, change one number, and the day's task is finished. That's why copying never feels like the wrong call. The bill doesn't arrive at the moment you make it.

It arrives months later, all at once. Pagedeck lived through exactly that. The rule that the free plan allows 20 documents existed in four separate places in the code: the check that blocks a new document, the screen that shows how many remain, the code that builds the warning message, and the monthly usage tally.

When the limit went up to 30, Theo found three of them and changed them. The fourth sat in the tally and never surfaced. Users could now create 25 documents while the screen still read "25 of 20 used," and the month-end tally flagged every account past 20 as over quota. Finding the mismatched state and unwinding it took far longer than the change itself had, and the support tickets arrived before anyone on the team noticed.

Don't Repeat Yourself (DRY) is the agreement not to create those situations. Spend a little more the first time so that later there is exactly one place to edit. The name comes straight from the instruction not to say the same thing twice.

The unit that matters is knowledge, not code. The same fact written down twice inside a system is duplication; two blocks of code that merely look alike are not.

One question separates them: will these two places change for the same reason? The 20-document limit living in four places is one piece of knowledge, because a pricing change has to move all four at once. Two screens that happen to share three identical lines, where one will change because of payment rules and the other because of notification rules, are strangers that resemble each other. Merging them buys nothing and costs a separation later.

How you pull something into one place depends on what it is.

1. Give values a name and one home. The number 20 stops appearing across the code and becomes a single named constant that everyone reads from.
2. Wrap calculations in a function. When the tax markup is written out separately in checkout, settlement, and receipts, the day the rate changes you have three places to find, and no way to prove you found them all.
3. Turn repeated screen pieces into components. Draw the same alert box into six screens by hand and changing one color becomes six edits.
4. The same applies outside the code. A password rule written once in the code and again in the help article is duplication too, and on the day it changes one side moves while the other doesn't, so a user follows the documentation and gets rejected.

The act of consolidating is refactoring: changing structure while leaving observable behavior alone. After the limit is pulled into one place, nothing on any user's screen should look different than it did before.

The principle gets invoked most often in code review. "Isn't this calculation also over in the other module?" is the everyday form of it. Content copied across several files is also a textbook code smell — a signal that structure has degraded even though nothing is broken yet.

It applies well beyond code. Defining colors and spacing once as design tokens and having every screen read from that set is the same move: when the brand color changes there is one place to edit. Generating API documentation from the code rather than writing it by hand follows the same reasoning, as does keeping values like server addresses in one configuration file instead of scattered through the source.

Where it isn't followed, the cost accrues as technical debt — deferred cleanup that comes back larger later. Duplication is the variety whose interest is easiest to see. A rule living in four places makes every change touching that rule four times heavier, and each round of edits creates a fresh chance of missing one of them.

"This calculation is sitting in checkout and settlement both. Let's pull it out."

The same knowledge is scattered, so gather it into one place.

"Don't force these together just to be DRY. They're about to diverge."

They only resemble each other today, and their reasons for changing differ.

"The wording is in the code and in the help doc separately, so they drifted apart again."

Duplication isn't confined to what lives inside the codebase.

After the document-limit incident, Pagedeck adopted a rule. Every number attached to a plan lives in one file, and the screens, the tally, and the warning copy all read from it. While building that file Theo wrote one line next to each value describing what it limits, so that whoever changes it next knows what else moves.

The payoff showed up at the next pricing revision. Mia adjusted the limits on three plans at once, there was a single file to edit, and the screens and the tally followed on their own. Work budgeted at two days finished before lunch, and nobody had to go hunting for a fourth place.

The most common misreading is that any code that looks alike has to be merged. The name sounds like a blanket ban on repetition, so the inference is easy. But merging makes two places into one body, and when one of them later needs to differ, that body has to be split again. In practice people add a flag instead of splitting, and a function carrying five such flags is harder to read than the two copies it replaced. The working rule that grew out of this is to wait until the third occurrence before consolidating, on the grounds that two similar things are a coincidence and three are a pattern.

The second one is treating the principle as a code-only concern. It was coined by programmers, so that reading comes naturally. The most expensive duplication, though, tends to sit between the code and everything around it — a refund window written as 7 days in the code and 14 days in the terms of service. Duplication inside the code at least has tests that might catch a divergence. A mismatch between code and documentation is caught by no tool at all, and customers find it first.