Why is YAGNI overrated?
Back in 2017, I attended a CodeEurope conference, where Niklas Gustavsson, the chief architect and VP of engineering at Spotify, gave a fascinating talk. He discussed Spotify’s approach to architecture and their in-house framework, Apollo. The talk revolved heavily around microservices – how they structured them, why they worked, and how they supported Spotify’s rapidly growing platform.
At the time, “microservices” wasn’t quite the buzzword it has become in 2024. It was a compelling but daunting concept, and I couldn’t help but wonder: did Spotify always know they needed this? So, during the Q&A, I asked Niklas whether their microservices architecture was baked in from the beginning. His answer? “Really good question. The answer is yes.”
Spotify, it turns out, had a chief architect at the very beginning ensuring they made solid architectural decisions right out of the gate.
This left me conflicted. On one hand, YAGNI (You Ain’t Gonna Need It) – the golden rule of simplicity and avoiding premature optimization – seemed to suggest otherwise. Start small, keep it simple, avoid unnecessary complexity. And yet, Spotify’s success seemed to hinge on the fact that they did bake in complexity from day one.
It got me thinking: is YAGNI overrated?
YAGNI: The Shortcut to Short-Term Thinking
After years of working in software engineering, I’ve noticed how often “YAGNI” is thrown around as an excuse to avoid solving problems proactively. In principle, it’s a great philosophy for reducing bloat. But in practice, it’s often misused to dodge the kind of engineering that requires big-picture thinking and long-term problem-solving.
Good engineering isn’t just about meeting today’s requirements – it’s about accounting for tomorrow’s possibilities. That’s why, when I joined Flowpass, I prioritized a forward-thinking architecture, even for a greenfield startup.
Flowpass offers a hybrid working office booking platform where users can reserve desks in co-working spaces, even for just a few hours. From day one, I advocated for a service-oriented architecture (SOA) – not full-blown microservices, but a modular system with enough flexibility to scale.
The architecture included:
- gRPC for service-to-service communication
- Kafka for asynchronous messaging (e.g., for email queues)
- A GraphQL backend-for-frontend
- Next.js for performant web delivery
At the time, it might have seemed like total overkill for a small startup. A whopping 75% of it fell squarely into YAGNI territory. But here’s the thing: YAGNI shouldn’t mean avoiding foresight.
What YAGNI Gets Wrong
The YAGNI philosophy assumes that building for the future is a waste of resources – that the future will sort itself out. But in reality, scaling an unprepared system is a nightmare.
Imagine starting with a monolith, as YAGNI advocates might suggest. If the software grows to 1 million users and requires a distributed system, taking apart a poorly written, non-modular monolith is nearly impossible. Even dismantling a well-written monolith can take months, if not years, and cost an extraordinary amount of engineering effort.
By contrast, investing 20% more effort upfront to bake in modularity and extensibility can save 90% of the resources required to re-engineer the system later. The worst-case scenario? You end up with a well-architected system that’s slightly over-engineered but still performs well.
The Case for Proactive Engineering
At Flowpass, the modular SOA architecture’s complexity wasn’t necessary initially, it laid the groundwork for future growth and allowed the company to adapt quickly as the product evolved. Sure, some of it might have been “YAGNI” at the time, but it made the system better in the long run.
YAGNI shouldn’t mean neglecting future possibilities – it should mean avoiding unnecessary bloat. There’s a difference between over-engineering and thoughtful engineering. A forward-thinking design is an investment in the longevity and adaptability of a system.
Conclusion: Do You Really Need YAGNI?
YAGNI is a tool, not a rule. Use it wisely. It’s helpful for avoiding premature optimization, but it should never be a shortcut to avoid thinking critically about the future. As engineers, our job is to solve problems – not just today’s problems, but tomorrow’s as well.
So, the next time someone says, “You ain’t gonna need it,” ask yourself: What will it cost if we do? What will it cost if we don’t?
Because in the end, a little overkill today might just save you a world of pain tomorrow.
Leave a Reply