Yes to YAGNI
Have you ever coded a feature to future-proof your product? One that wasn’t core to your offering at the time of development, but you were pretty sure you’d need it to stay competitive moving forwards.
Except that it later turned out that you didn’t need that functionality at all. Do you then throw away that effort and resource that went into the feature, or do you leave it in your software anyway? You end up with overengineered software and all the issues that come with it.
This is the problem that the YAGNI approach seeks to address. But what is YAGNI, and how can it solve your overengineering woes?
What is YAGNI?
YAGNI stands for ‘You Aren’t Gonna Need It’. It emerged as a mantra with origins in extreme programming (XP). Essentially, YAGNI declares war on pre-emptively future-proofing your software.
Following YAGNI means not adding any new features until you know for certain that you need them. Even if you think you might need the functionality later down the line, YAGNI operates under the presumption that the chances are, you aren’t gonna need it.
The idea behind YAGNI is that predicting what you need in the future is extraordinarily hard. Plus, it’s often costly, regardless of whether your predictions are correct.
So, saying yes to YAGNI simply makes you hold off on development until you know that the feature is worth spending time and resources on.
How does it work?
YAGNI best fits with an agile development strategy. It relies on short development cycles and frequent releases. This only gives you the space to focus on the present needs of your users. Future needs get another development cycle closer to the time. (When you know what they are.)
For YAGNI to work, though, you need to keep your code clean and simple. As such, ‘you aren’t gonna need it’ applies only to adding functionality that you think you might need one day. It does not apply to any efforts to make the software easier to modify. (I.e. through refactoring.)
Similarly, YAGNI shouldn’t handicap your future efforts. It’s important to continue future-proofing your product with ongoing preventive maintenance and design evolutions.
Practising YAGNI, then, simply means only implementing these decisions enough to fit the current need. You can build on them as and when the functionality is needed.
Why say yes to YAGNI?
Saying yes to YAGNI reduces the time spent on unnecessary work. As such, it directly addresses the problem of overengineering.
For a start, the approach means reduced development costs. When you ensure that you’re only spending on the features you know you need, you avoid wasting resources on unnecessary functionality.
In fact, a common symptom of overengineering is feature creep. With YAGNI, this is easy to avoid — you aren’t coding features that aren’t needed, and so you can’t add them to your program. As a result, YAGNI improves product simplicity and usability — making for a better user experience.
Finally, YAGNI can have a positive impact on team productivity and morale. Developers know their work is useful, and they don’t face the frustration of their efforts going unused.
Crucially, YAGNI means your software becomes simpler and easier to manage, update, and scale.
The costs of saying no to YAGNI
Beyond the benefits, saying yes to YAGNI helps you avoid needless costs. For instance:
- Development costs
You spend money and time on features that aren’t used. As a result, you see little to no ROI and can hurt developer morale in the process.
- Delay costs
When you make needed features in advance, you must wait to receive a return on investment.
- Usability costs
When you build things you don’t yet need, you increase the risk of feature creep and overly complex software. This hurts the usability of your end-product.
When a foreseen feature finally becomes needed, it’ll often need reworking to fit with the more recent code that makes up your software. So, you add to the costs of developing that one feature.
You aren’t gonna need it.
As a result of YAGNI, you build up your software over time. As needs grow and change, you shape your program into the product that best serves your users and their pain points. And this happens without hours of work and countless features hitting the cutting room floor.
When it comes to the future of your software, knowing exactly what you will need and when is near impossible. The future is a mystery — and that feature you have planned? You aren’t gonna need it.
Useful links
Overengineered software and the Juicero problem
