You Aren’t Going to Need It (YAGNI) Principle Explained
A long time ago I read this great article from Martin Fowler explaining what YAGNI was. When I brought up this principle to a couple people the other day they had never heard of it. It seems more than ever with so many people coming out with “the right way” to do things and so many different options that are becoming available to come back and remember this principle.
YAGNI - You aren’t going to need it
You may look at this principle and say “well duh” OR you may be one of those people who look at it and say well what if you do that’s why we implement things to begin with to make our future lives easier. You also may think this may be pretty straight forward. But think how many times in the last week have you implemented something because you thought you MIGHT need it or implemented something in a way that may have been more complicated but it was more open ended so if you wanted to add something to it later you could.
Premature optimization/implementation
That leads us to one of the things this principle tries to keep us away from which is premature optimization or implementation. There is no reason to implement something more complicated just so that down the road you may be able to make it more flexible. This makes the code more unmaintable and can lead to more complication by trying to make it fit too many scenarios rather than the scenario it was originally intended for. We see this a lot with API endpoints where we build these endpoints that can accept everything and do everything based off flags when really the endpoints should be very specific to the exact information you need.
This goes hand in hand with premature optimization. If you think something may be reusable don’t make it reusable until it needs to be don’t add a layer of complication and abstraction just because you think in the future it may be reusable. Make it reusable when the A/C calls for it and no sooner.
YAGNI even goes as far as to say even if you know its in the pipeline for a quarter or two down the road don’t implement it until you need to. Right now implement what you know needs to be implemented. Get the feature out. When you need to implement the next part of it update it as needed then. Don’t make it more complicated now for the potential in the future just get the feature out.
It’s a bit extreme
YAGNI as a principle I think is really great and something we should all be keeping in the back of our minds. Rather than building these crazy applications that can do a million things with ease of potential future in mind we should be trying to tackle the issues in front of us. However, YAGNI as a principle as layer out in ExtremePrinciples is just that… Extreme. It takes to to a level that you have to start outweighing the cost of those decisions (just like any other decision including going the non YAGNI route). It can be very costly both time and effort to not keep the future in mind when building out applications. The cost and effort of refactoring to allow for certain things in the future can be a huge lift with a lot of dev time.
This trade-off is something that Martin Fowler mentions at the bottom of his article as well. Sometimes it can cause an issue to be too strict and to not take the future into consideration.
So do I follow YAGNI?
Yes and no. While I think YAGNI as a principle is a great concept I lean more in the middle of the road. I think not bringing in libraries until they are needed, or not making things optimized/reusable until they need to be is something really important that we should all keep in mind while developing. While trying to account for all future possibilities is great it also comes as a cost of having to support that extra functionality that is usually more complicated just so that maybe one day it can be flexible IF you need it. I think there should be a balance just like everything else
