The Two Principles That Made Me Delete More Code Than I Write: YAGNI & KISS

Early in my career I measured a good day by how much code I wrote. More classes, more abstractions, more “flexibility for later” — that felt like progress.

A few years and a lot of maintenance pain later, I measure a good day by how much code I didn’t write.

That shift comes down to two principles that sound almost too simple to matter: YAGNI and KISS. They’re the first things I reach for in a code review, and the hardest to actually follow — because both ask you to do less, and doing less feels like not trying hard enough.

Let’s break them down.

---

YAGNI — You Aren’t Gonna Need It

Build for the requirement in front of you — not the future you imagine.

YAGNI says: add functionality only when it’s actually needed, not when you foresee needing it. Every “just in case” feature is code you have to write, test, document, and maintain forever — often for a future that never arrives.

You’re probably violating YAGNI when…

• You catch yourself saying “we might need to support X later” — and build X now.
• You add a config flag that only ever has one value.
• You introduce an abstraction (interface, base class, strategy) with exactly one implementation.
• There’s a database column nothing reads yet.

What it actually costs you

The cost isn’t just the time to build the speculative thing. It’s everything downstream:

• The time to maintain and test code nobody uses.
• The complexity every other engineer now has to read around.
• Bugs hiding in code paths that never even run in production.

Speculative generality is a loan you take out against your future self — at a brutal interest rate.

How to apply it

• Ask one question: “Is this required for the story I’m shipping today?” If no → don’t build it.
• Delete speculative code. git remembers it if you ever turn out to be right.
• Build the simple version now; refactor when the real requirement actually lands.
• Follow the order: make it work → make it right → make it fast. Not the reverse.

YAGNI is not an excuse for

This is where people misuse it. YAGNI kills speculative features — not good engineering. It is never a reason to skip error handling, ignore security, or write code that’s genuinely impossible to extend later. Simplicity and sloppiness are not the same thing.

Save this one for your next code review.

---

KISS — Keep It Simple, Stupid

Simplicity isn’t a lack of skill. It’s the hardest skill.

If YAGNI is about how much you build, KISS is about how you build it. It says: the simplest solution that fully solves the problem is the best one. Optimize for the next person who reads the code — which, nine times out of ten, is future you at 2am during an incident.

You’re probably overcomplicating it when…

• A one-liner quietly grew into a four-level-deep “clever” chain nobody can read.
• You reach for a design pattern before you actually have the problem it solves.
• Your logic is a pyramid of deeply nested if/else blocks.
• You’re reinventing something the standard library already does.
• You need a comment to explain what the code does — not just why.

How to apply it

• Write it the boring, obvious way first. You can always make it clever later (you usually won’t need to).
• Flatten nesting with early returns / guard clauses.
• One function = one job. If you can’t give it a clear name, it’s doing too much.
• Prefer clear names over clever tricks.
• The litmus test: if you can’t explain it in one sentence, simplify it.

The tension with DRY

KISS and DRY (Don’t Repeat Yourself) will occasionally fight, and when they do, KISS usually wins:

• A little duplication is cheaper than the wrong abstraction.
• Don’t couple two pieces of code together just because they look similar today. Similar-looking code that changes for different reasons is not duplication — it just rhymes.

Clever code impresses in a PR. Simple code survives in production.

---

They’re two sides of the same coin

Notice the through-line: both principles are about restraint.

• YAGNI stops you from building things you don’t need.
• KISS stops you from over-building the things you do need.

Together they push you toward the same place — the smallest, clearest amount of code that solves the actual problem. And restraint, it turns out, is the senior skill. Anyone can add. Knowing what not to add — and being confident enough to delete the speculative abstraction someone (maybe you) was proud of — is what separates code that ages well from code that becomes a maintenance tax.

As Einstein (supposedly) put it: “Everything should be made as simple as possible, but not simpler.”

The next time you’re about to add a flag, an interface, or a clever one-liner, pause and ask: am I solving today’s problem, or a problem I’m imagining?

The best code is the code you didn’t have to write.