Programming Fundamentals
DRY, KISS & YAGNI
Three guardrails for everyday design: don't repeat knowledge (DRY), prefer the simplest thing that works (KISS), and don't build what nobody has asked for yet (YAGNI). Together they fight the two classic failure modes — copy-paste drift and speculative complexity. The catch: DRY over-applied creates the wrong abstraction, which costs more than the duplication it removed.
Purpose
DRY (Don't Repeat Yourself), KISS (Keep It Simple) and YAGNI (You Aren't Gonna Need It) are rules of thumb that keep a codebase cheap to change. DRY says every piece of knowledge — a business rule, a constant, a format — should live in exactly one place, so a change is made once instead of hunted down in five copies. KISS says complexity must earn its keep. YAGNI says code built for an imagined future is usually waste, because the future arrives looking different.
When to Use It
They bite hardest at review time: a second copy of a business rule is a DRY flag; a clever generic helper with one caller is a KISS and YAGNI flag; a configuration option nobody asked for is pure YAGNI. They are also tie-breakers — when two designs both work, the simpler, less speculative one wins by default.
The nuance that matters: DRY is about knowledge, not text. Two functions that happen to look alike but belong to different domains are not duplication — merging them couples things that change for different reasons, and the shared helper soon sprouts flags.
Trade-offs
Over-applied DRY produces premature abstraction: one shared function bent by five callers is worse than five honest copies — duplication is cheaper than the wrong abstraction. KISS can be misused to veto necessary design, and YAGNI to excuse skipping groundwork that genuinely is needed now, like tests or migrations. All three are heuristics, not laws.
Implementation
Follow the rule of three: tolerate the second copy, extract on the third, and name the extracted concept after the knowledge it holds, not the code it deduplicates. Prefer plain functions over frameworks, delete speculative parameters, and when unsure whether an abstraction is ready — wait. Un-inlining later is far easier than un-abstracting.