Posted on
4 minutes to read
YAGNI - You aren't gonna need it - revisited
Scope it till it hurts.
Article #1 in my new "software ideas revisited" series.
There’s a moment in every project where someone says, “Wouldn’t it be cool if…”. A few hours later, your well scoped project has three new features and is now late. That’s when it’s time to say the words out loud: you aren’t gonna need it.
"You Aren’t Gonna Need It" is a well-trodden software engineering mantra. It's a reminder not to build speculative features you haven’t yet proven the need for -- and a mantra that largely holds up today.
Some examples of times I've encountered scope creep:
- Over-complicated modelling ideas where fields are implemented which could possibly be useful in the future, but have no current use.
- Implementing an API endpoint that you have zero practical uses for today.
- Adding database indexes before you have a query that might use them (I'd argue that early optimisation is a form of engineering-led scope creep / YAGNI).
- Implementing advanced search features in a CMS that no-one has asked for or will likely need.
- Creating a whole new feature for a community... which no-one then notices or likes (I have been guilty of this more than once!).
Being generous, the root of this probably comes from engineers trying to be dutiful, pro-active and attempting to make choices today that make things better in the long-term -- which is very noble! And most engineers or product people can probably point to one or two examples in their career where they shipped more than they truly needed, but it actually paid off in the future. Well done! But, having wins like that early on in your career can make you over-confident about shipping tomorrow's features today. The approach works, until it doesn't.
The temptation to build "the full thing" is strong, especially when your team has the talent to do it. (And I have worked in very talented teams!) But building too much too soon is a trap. It slows you down, muddies your true goals, and leaves you emotionally invested in features no one asked for.
Every great product starts with a brutal trade-off. Not a compromise. A choice. Try and consciously make strong choices.
Some red flags to look out for:
- "We’ll need it eventually." (If that's true, we'll build it eventually.)
- "Our competitor has it." (How do you know it's working for them?)
- "It’s just a small tweak." (Every developing adding their own flavour of small tweaks can add up to a big delay.)
Before you say yes to adding scope, it can be helpful to ask yourself -- and your team:
- Have we cut enough to make this uncomfortable?
- Have we removed enough that we’re just a bit nervous it might be too lean?
If the answer to both is "yes" -- it's probably a good sign. That means you’re probably close to the version that can ship, teach you something, and earn the right to evolve.
For me, Shape Up, Basecamp’s product methodology, frames these questions really nicely by advising you to perform "scope hammering". Scope hammering is the act of honing your requirements to allow you to ship something meaningful inside a fixed time box.
In Shape Up, this is the core tension: you don't shrink the deadline, you shrink the scope. You're not giving teams "how" to do it, you're giving them the appetite -- how much time you're willing to spend. Then they figure out the leanest, smartest way to hit the mark. I really, really like this approach as it makes shipping more likely.
Hammering in practice
Frame things using the question: what’s the most meaningful thing we can ship that doesn’t break the budget, the deadline, or our brains?
Start with the appetite. If we only had 6 weeks (or 2 weeks, or 1 -- whatever your team uses for a typical cycle time), what’s the version of the idea that fits?
Keep the pitch sacred. Once scoped, we don’t sneak in extras. New ideas are great (keep track of them!), but they go into the next cycle -- not this one.
Pre-scope to the extreme. Shape before work hits a sprint, so engineering isn’t stuck figuring out what to build and how to build it at the same time.
Ship, shape, ship, shape
Scoping till it hurts doesn’t mean leaving projects in a lurch -- and YAGNI shouldn't feel demoralising or disempowering. Paying attention to scope means starting smaller, shipping sooner, and iterating smarter -- and come back to the remaining work when it's earned time on the schedule.
Remember: every feature you cut is a future improvement you can actually make. Every unnecessary complexity you dodge is a bug you’ll never have to fix. And every version you ship is a chance to learn what really matters.
So, ship the core, and remember -- you can always come back to your early optimisations, modelling complications, and features for power-users later.
