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

Early in my career I used to measure a good day by how much code I wrote. More classes, more abstractions, more “flexibility for the future”, all of that felt like real progress.

A few years and a lot of maintenance pain later, I now measure a good day by how much code I did not write.

That shift comes down to two principles that sound almost too simple to matter, YAGNI and KISS. These are the first two things I look for in a code review, and also the hardest ones to actually follow, because both of them ask you to do less, and doing less feels like you are 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 for the future you are imagining.

YAGNI says, add functionality only when it is actually needed, not when you think you will need it later. Every “just in case” feature is code that you have to write, test, document and maintain forever, and often for a future that never even arrives.

You are probably violating YAGNI when…

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

What it actually costs you

The cost is not just the time to build that speculative thing. It is everything that comes after it:

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

Speculative generality is like a loan you take against your future self, and the interest rate is brutal.

How to apply it

• Ask yourself one question, “is this needed for the story I am shipping today?” If the answer is no, do not build it.
• Delete the speculative code. git will remember it if you ever turn out to be right.
• Build the simple version now, and refactor when the real requirement actually lands.
• Follow the order, make it work, then make it right, then make it fast. Not the other way around.

YAGNI is not an excuse for

This is where people misuse it. YAGNI kills speculative features, it does not kill good engineering. It is never a reason to skip error handling, or ignore security, or write code that is genuinely impossible to extend later. Simplicity and sloppiness are two very different things.

Save this one for your next code review.

---

KISS, Keep It Simple, Stupid

Simplicity is not a lack of skill. It is actually 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. Write for the next person who reads the code, and nine times out of ten that person is you, at 2am, during an incident.

You are probably overcomplicating it when…

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

How to apply it

• Write it the boring, obvious way first. You can always make it clever later (and usually you will not need to).
• Flatten the nesting with early returns and guard clauses.
• One function should do one job. If you cannot give it a clear name, it is doing too much.
• Prefer clear names over clever tricks.
• A simple test, if you cannot explain it in one sentence, simplify it.

The tension with DRY

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

• A little bit of duplication is cheaper than the wrong abstraction.
• Do not couple two pieces of code together just because they look similar today. Code that looks similar but changes for different reasons is not really duplication, it just rhymes.

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

---

They are two sides of the same coin

If you notice, both principles are really about the same thing, restraint.

• YAGNI stops you from building things that you do not need.
• KISS stops you from over building the things that you do need.

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

As Einstein (supposedly) said, “everything should be made as simple as possible, but not simpler.”

So the next time you are about to add a flag, or an interface, or a clever one liner, just pause for a second and ask, am I solving today’s problem, or a problem that I am only imagining?

The best code is the code that you did not have to write.