DRY, KISS, YAGNI & Naming
Developers carry a few short principles that guide everyday decisions, and they cite them constantly: DRY, KISS, and YAGNI. Plus a quieter superpower that beats them all — good naming. These are rules of thumb, not laws, but knowing them tells you what reviewers are getting at when they quote three letters at you.
A kitchen makes a clean picture: one labeled spice rack (DRY, good names) instead of duplicate jars hidden in three different drawers. Find what you need, know what it is, and don't keep three half-empty copies.
| Principle | Stands for | In one line |
|---|---|---|
| DRY | Don't Repeat Yourself | One source of truth for each piece of knowledge |
| KISS | Keep It Simple | The simplest thing that works |
| YAGNI | You Aren't Gonna Need It | Don't build for an imagined future |
DRY: Don't Repeat Yourself
DRY says each piece of knowledge should live in exactly one place. When the same logic is copied into three spots, the copies drift apart over time — you fix a bug in one and forget the others. Pull the logic into one place, and a fix there is a fix everywhere. The subtle part: DRY is about duplicated knowledge, not identical-looking lines; some surface repetition is fine if it represents genuinely separate ideas.
KISS: Keep It Simple
KISS reminds you that the simplest solution that works is usually the best one. Complexity is a cost paid by every future reader, so you should add it only when the problem genuinely requires it. KISS doesn't mean dumb or simplistic code — it means no needless complexity, no clever machinery where a plain approach would do.
YAGNI: You Aren't Gonna Need It
YAGNI warns against building features and flexibility for a future that may never come. It's tempting to add "just in case" options and hooks, but each one is code to build, test, and maintain forever — for a need that often never arrives. Build what's needed now; add more when the need is real. YAGNI means don't build ahead, which is different from refusing to plan ahead.
Naming: The Cheapest Documentation
The quiet superpower is naming. A well-named function or variable removes the need for a comment, because the name says what it is. currentStreak needs no explanation; x2 needs a paragraph. Good names are the cheapest, most durable documentation there is — they travel with the code and never go stale. Most senior developers will tell you naming things well is one of the genuinely hard, genuinely valuable skills.
On Cadence, the team finds the streak calculation copied in three places — a clear DRY violation, and sure enough one copy already has a bug the others don't. They pull it into one well-named function, currentStreak(). Now it's fixed once and correct everywhere, and the name alone tells the next reader exactly what it does. DRY and naming, doing their quiet work.
- "DRY means never typing anything twice." It's about not duplicating knowledge, not keystrokes. Two bits of code that look alike but mean different things can stay separate.
- "KISS means writing dumb, simplistic code." It means avoiding needless complexity. Some problems are genuinely hard and need real machinery; KISS just forbids adding complexity that isn't earned.
- "YAGNI means never planning ahead at all." It means don't build ahead for imagined needs. You can and should plan and design for the future — you just don't write speculative code for it now.
- These are the phrases reviewers cite every day — internalizing them lets you understand feedback and avoid the most common quality slips before they happen.
- Good naming is a skill you can practice immediately and one of the highest-leverage habits in all of programming, regardless of language.
- Together they keep code simple, single-sourced, and self-explaining — the practical heart of writing software that stays easy to change.
Knowledge Check
What does the DRY principle really say?
- Each piece of knowledge should live in exactly one place in the code
- You should literally never type two even slightly similar lines of code ever again
- You should remove every comment from the entire codebase
- You should always write code in the fewest possible lines
What does KISS mean in practice?
- Use the simplest solution that works and avoid needless complexity
- Always write the most basic and simplistic code possible, no matter what
- Use the absolute smallest number of lines that is possible
- Never use any advanced feature of the programming language
What is the point of YAGNI?
- Don't build features for an imagined future; build what's needed now
- You should never plan or design for the future in any way
- You should delete any existing feature that users are currently relying on
- You don't need to test the code you write for the project
Why is good naming called "the cheapest documentation"?
- A clear name explains itself in the code and never goes stale
- Because well-named code always runs faster than badly-named code
- Because good names completely remove the need for any docs at all
- Because short cryptic names save space and typing effort
You got correct