DRY and the Cost of a Value Typed Out More Than Once

A duplicated value (a timeout duration, a hex color, a threshold number) typed out directly in more than one place in a codebase is a specific, well-named kind of technical debt: knowledge that exists in two places instead of one. It isn't a bug the moment it's written. It becomes one later, quietly, when someone updates one occurrence and has no way of knowing a second copy exists somewhere else, and the two silently drift apart.

The principle, and where the line actually is

The formal name for the underlying idea is DRY: Don't Repeat Yourself, coined in The Pragmatic Programmer by Andrew Hunt and David Thomas, and worth quoting precisely rather than paraphrasing: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." The closely related, often paired term is single source of truth: the practice of defining a value exactly once and referencing it everywhere it's needed, rather than retyping it.

The reason this matters in practice, not just in principle, is that duplication of this kind is invisible by construction. Nobody notices two matching literals by reading code casually the way they'd notice a visibly broken function. It surfaces only when the two copies stop matching: a bug report about inconsistent behavior, a design review catching a color that's "close but not quite" the brand's actual palette. At that point the fix is easy, but finding the second copy that also needs updating usually isn't obvious from the bug report alone.

It's worth pairing DRY with the caveat that almost every serious treatment of the principle includes: it applies to knowledge, not to every value that happens to look similar. Two numbers that are coincidentally both 5 for entirely unrelated reasons don't need to be unified into one shared constant. Doing so anyway produces what's often called a "wrong abstraction," where code that should be free to change independently gets artificially coupled because it once shared a number. The test worth applying before extracting a constant: if one of these values changed, would the other one need to change too, because they represent the same underlying fact? If yes, name it once. If the similarity is coincidental, leave them as they are.

Where this shows up

Any codebase with more than one place that needs the same fact (a timeout, a limit, a color, a threshold, a URL, a magic string used as a lookup key) is a candidate. It's especially easy to introduce by accident when a piece of UI or logic gets copy-pasted as a starting point for a similar one nearby: the copy carries the original's literal values along with it, and nothing points out that they're now duplicated rather than shared.

// Scattered: the same duration typed out in two unrelated files.
setTimeout(() => setCopied(false), 1500);
// ...elsewhere...
setTimeout(() => setSaved(false), 1500);
 
// Named once, referenced everywhere:
export const TRANSIENT_STATE_REVERT_MS = 1500;
 
setTimeout(() => setCopied(false), TRANSIENT_STATE_REVERT_MS);
setTimeout(() => setSaved(false), TRANSIENT_STATE_REVERT_MS);

A real example of the more common, easy-to-miss case: a file defining a named color palette for one purpose, but then re-typing the same hex values by hand elsewhere in the same file for a different chart or legend, rather than referencing the palette that already exists. The fix is rarely architecturally interesting: pull the duplicated literal into a constant, reference it from both places. But finding it usually requires a deliberate look through a file for repeated literals, the same way finding an oversized dependency usually requires deliberately running a bundle analyzer rather than noticing it by eye.

Applying it

• Before typing a literal value a second time, check whether it already exists as a named constant somewhere. If it doesn't yet but probably should, that's the moment to create one, not after the second copy has already drifted.
• Apply the "would both need to change together" test before extracting a shared constant from two similar-looking values. Don't couple values that are only coincidentally the same.
• When copying an existing component or block of logic as a starting point for something similar, treat any literal values it carries as a signal to check: should this new code reference the original's constant, or does it genuinely need its own?
• Periodic review, not just reacting to a bug: the same duplication that causes a real inconsistency later is invisible during ordinary reading, so it's worth an occasional deliberate pass rather than waiting for it to surface on its own.