Cathedrals are easy. Space boats are hard.

Radical concepts are not add-ons to our current view. They force us to look at the world with a different set of eyes. After this paradigm shift, it’s easy to forget that not everyone is on the same page.

One of these radical ideas is the YAGNI rule and @Adelius3 posed a great question recently: how do I get people to embrace YAGNI?


Let’s start at the beginning. You Aint Gonna Need It was one of the core principles of eXtreme Programming. Ron Jeffries, one of the smart brains behind XP, explained it like this :

“Always implement things when you actually need them, never when you just foresee that you need them.”

A minority of devs will think “Duh”, but most of us will HATE it. Why is that?

It goes against the core of what we’ve been taught a developer does: we come up with a solution and build it. The coder is an architect, construction worker and visionary rolled in one.

Part of the tenets of XP was to refute this role. The construction metaphor is the wrong lens to look at coding. We’re not visionaries. We can only find the solution by building it. The coder is a detective, a scientist.

On the other side of the Business/IT divide, the Lean Startup shows us the same clash. Lean entrepreneurs know they can’t foresee the future, so they build the smallest increment that will validate their hypothesis: the Minimal Viable Product. The majority of business people HATE it. I know what I want, right?

That’s why it’s so difficult to rationally explain YAGNI to people. It ties into the emotional perception of their job. What kind of problem solver am I if I admit I don’t know the solution up front? How does “Dunno. Let’s find out.” make me sound like an expert?


If we want to convince devs that YAGNI is a golden asset, we need to show them the immediate benefits. We need to reframe the way they look at their job.

By doing the simplest thing you can (DTSTTCPW, look it up) you shorten your iterations. You always have a potentially shippable increment on your hands. And best of all? Those hands are immediately free to build The Next Awesome Thing!

Hardcode that one endpoint instead of loading a properties file. Call the object directly instead of abstracting it away through interfaces and inheritance. You can always refactor later. At a better time. When a design emerges and you need to refactor.

You’ll end up with clean code that’s engineered just right. You’ll discover the right design no one could predict. Not even you.

But those are the technical nitty-gritty details. Software developers are not just coders. We design and build products. And that’s where YAGNI/Lean entrepreneurship really shine.

“I’d love to get Slack notifications when a user completes an order, but I’m still busy building that User Profile edit screen”

That’s not a state you want to be in as a developer! You want to push out a working increment, straighten your back and look your next most-valuable target in the eye. Your time is too valuable to spend on anything else.

YAGNI guarantees that you’re always working on the most important part. Not some fluff that ended up in the scope document. Not some feature we think we might need. The most pressing and valuable feature and only that. Don’t be bogged down by upfront design and requirements. Live on the cutting edge of your product.

It defines the developer as a scientist/innovator. Not trying to come up with a timeless, perfect design, but always looking to solve the problem at hand.

There’s plenty of cathedrals already and they all look alike. There’s a clear-cut way to build them. That’s construction, not development.

What we want to build are the rocketships, transporters and space boats that will take us to places we can’t even predict.

We accept that we don’t know what this product will look like, but we’re pretty sure You’re Gonna Need It.