I've spent fifteen years watching developers misquote Kent Beck. They wave You Aren't Gonna Need It like a holy text, slashing features before they're even born. They think YAGNI is about efficiency. It's not. It never was.
Beck's latest piece lands like a grenade in a philosophy seminar. He writes that the real cost of YAGNI—the cost we were never supposed to pay—is not in lines of code or CPU cycles. It's in learning. Or rather, in the learning we skip when we refuse to build something we think we don't need.
I've been in those meetings. Product manager sketches a feature. The lead developer scoffs: "That's gold-plating. YAGNI." Everyone nods. The feature dies. And six months later, we're tearing the architecture apart to bolt on exactly that feature, but now it's harder, uglier, and the team doesn't understand the domain well enough to do it right.
The Cost That Hides in Plain Sight
Beck's argument is subtle. He says that when you implement something "just in case," you're not wasting time—you're buying information. That prototype? That extra endpoint? That table you didn't need yet? Those are experiments. They teach you whether the idea works, whether the design holds, whether the customer actually wants it.
"You can't learn about a system without building it. And you can't learn about the future without making something that touches it."
The real cost of YAGNI, Beck argues, is the learning you never do. The questions you never ask. The feedback you never get until it's too late. That's a cost no spreadsheet captures.
I've seen projects where the team was so disciplined about YAGNI that they built a perfectly lean system—and then the market shifted, and they had no clue how to adapt because they had never explored the adjacent possibilities. They optimized for the known and made themselves blind to the unknown.
The XP Context Everyone Forgets
People forget that YAGNI came from Extreme Programming, which also includes refactoring and continuous design. The whole point was that you could defer decisions because you had the discipline to change your mind later. You weren't supposed to use YAGNI as an excuse to never build anything speculative. You were supposed to use it as a license to build fast, learn fast, and throw away fast.
But somewhere along the way, YAGNI got weaponized. It became a club to beat back curiosity, a justification for minimalism that bordered on paralysis.
I remember a startup I advised. The CTO was a YAGNI zealot. Every feature request met with "YAGNI." Every database index proposal met with "YAGNI." Every third-party integration met with "YAGNI." The product was lean. It was also dead. They ran out of runway before they ran out of quotes.
What Beck Is Really Saying
Beck's essay isn't an anti-YAGNI manifesto. It's a call to understand the trade-off. He's saying: Admit what you're paying when you say no. You're paying in ignorance. You're paying in missed feedback. You're paying in the compound interest of what you don't know.
The cost of building something you don't need is measurable: a few hours, some server space, maybe a headache. The cost of not building something you do need? That's a death spiral.
"YAGNI was never about avoiding cost. It was about choosing which costs to pay now vs. later. Most of the time, the cost of learning is worth paying early."
This reframes the argument entirely. Suddenly, the question isn't "Will we need this?" It's "What will we learn by building this?"
I think of every half-baked prototype I've ever written. Most ended up in the trash. But a few—just a few—uncovered assumptions that saved us from building entire wrong products. Those prototypes paid for themselves a hundred times over.
The Practical Takeaway
So what does this mean for your next sprint? It doesn't mean throw YAGNI out the window. It means use it as a scalpel, not a sledgehammer. Before you kill a feature, ask: What would we learn by building a tiny version of this? If the answer is "nothing new," then YAGNI applies. But if the answer is "we'd find out if the API works" or "we'd see if customers actually click this button"—then the cost of not building it is higher than the cost of building it.
Beck is giving us permission to be wrong. To build things that might fail. To treat code as a learning tool, not just a delivery mechanism.
I'm taking that permission. I'm going to build something stupid tomorrow. Something I probably won't need. But I bet I'll learn something I do.
