Some of the most useful advice in software fits on a sticky note. DRY, YAGNI, and KISS are three such rules of thumb, each a short, memorable nudge toward code that stays simple and easy to change. None of them is a deep theory — they're hard-won habits that experienced developers reach for again and again.
The shared goal behind all three is the same: keep a codebase changeable. Software is read and modified far more often than it is first written, and these principles each attack a different way that code quietly becomes harder to touch. The animation below steps through them in order — DRY, then YAGNI, then KISS — so you can take each idea on its own before we look at it up close.
DRY · Don't Repeat Yourself — Each piece of knowledge has one authoritative home — duplication breeds bugs.
Don't treat these as a checklist to satisfy on every line. The real skill is knowing when each one applies — and noticing when two of them are pulling in opposite directions, which happens more often than the slogans admit.
DRY — Don't Repeat Yourself
DRY says that every piece of knowledge in a system should have a single, authoritative home. When the same rule, fact, or decision is written down in more than one place, every future change has to be made in all of them — and the day someone updates one copy and forgets the others, the copies disagree and a bug is born.
Imagine a tax rate hard-coded into the checkout page, the invoice generator, and a nightly report. When the rate changes, you must remember to edit three files; miss one and your numbers silently drift apart. DRY pushes you to define that rate once and have everyone refer to it.
DRY is about duplicated knowledge, not duplicated text. Two functions that happen to look similar today but represent genuinely different ideas — say, validating a username and validating a password — are not a DRY violation, even if the code lines match. Forcing unrelated things to share code just because it looks the same is how DRY goes wrong.
YAGNI — You Aren't Gonna Need It
YAGNI says: don't build a capability for an imagined future — build it when the need is actually real. It came out of the Extreme Programming community and was popularized by people like Kent Beck and Martin Fowler as a counterweight to over-engineering.
The temptation is everywhere. You're writing a feature that supports one currency, and you think, "I'll make it handle any currency, just in case." So you add configuration, abstraction layers, and tests for cases no one has asked for. Most of that speculative work is wasted: the future requirement either never arrives or arrives looking nothing like what you guessed, so you have to tear out your clever generality anyway. YAGNI says to solve today's problem well and add the second currency the day a second currency is real.
KISS — Keep It Simple
KISS — "Keep It Simple" — says to prefer the simplest solution that actually solves the problem. Complexity is not free: every extra layer, clever trick, or moving part is something a future reader has to understand and a future change has to navigate. That cost is paid over and over, long after the code is written.
If a plain loop does the job, you usually don't need a configurable rules engine. If a single function is clear, you don't need to scatter the logic across five tiny classes to feel "clean." Simple doesn't mean crude — it means choosing the most direct approach that meets the real requirements, and resisting complexity that doesn't earn its keep.
When the rules pull against each other
These principles are guidance, not gospel, and they don't always agree. The sharpest tension is between DRY and the others. Chasing DRY too aggressively — collapsing every passage that looks alike into one shared abstraction — can land you with the wrong abstraction: a tangled helper that several callers must all bend to, which actually raises coupling and makes change harder, the opposite of what DRY promised.
KISS and YAGNI often act as the brakes here. A little honest duplication can be simpler and looser than a premature abstraction, and YAGNI reminds you not to generalize for callers that don't yet exist. The right move is judgment: wait until the duplication clearly represents the same knowledge before unifying it.
Beware turning any of these into dogma. "But that's not DRY!" is not, by itself, an argument — neither is "KISS!" used to shoot down structure the code genuinely needs. The slogans are heuristics to prompt thinking, not trump cards that end the discussion.
Used with judgment, DRY, YAGNI, and KISS reinforce each other: one source of truth, no speculative baggage, and the simplest design that works. They also complement the more detailed object-oriented guidance in SOLID, which gives you concrete techniques for where to draw boundaries once you've decided something is worth abstracting. Keep all of them as lenses you look through, not boxes you tick.