DRY - Don't Repeat Yourself 🌵

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

DRY is one of the first principles every developer learns — and one of the most frequently misapplied. The goal isn't to eliminate all duplication. It's to ensure that when you change a business rule or a piece of logic, you change it in exactly one place.

Where DRY helps

When knowledge is genuinely duplicated — the same validation rule in three services, the same config value hardcoded in five files, the same transformation logic copy-pasted across modules — DRY eliminates the drift. One source of truth means one place to update and one place to test.

Where DRY hurts

The danger is premature abstraction. Two pieces of code that look similar today might evolve in completely different directions tomorrow. If you merge them into a shared function too early, you end up with a function full of conditionals and parameters that serves no one well.

A good rule: duplicate first, abstract second. Let the duplication exist until you've seen the pattern repeat at least two or three times and you understand what's truly shared versus what just looks similar. The cost of the wrong abstraction is almost always higher than the cost of a little duplication.

Practical applications

• Shared configuration — API keys, environment variables, feature flags: one source, referenced everywhere.
• Libraries over copy-paste — If multiple services need the same logic, extract it into a library with its own versioning and tests. But be deliberate — a shared library creates coupling.
• Automation over manual repetition — If you're doing the same manual step twice a week, script it. The third time pays for itself.

Bottom line

DRY is about knowledge, not characters. Two functions with identical code aren't necessarily duplicated if they represent different business concepts that happen to look the same today. Apply DRY to what you know, not to what you see.