You aren't gonna need it
Future is unknowable, prepare for it
We, programmers, proud ourselves on being smart. Solving tough technical challenges are our bread and butter.
Most often the problems we need to solve are complex, requiring a lot of thought and dedication. It’s understandable that on every step of the way we are trying to make our life a bit easier.
It would be great if the solution to our current challenge helped to solve future ones. It would save the effort and we could tackle next problem quicker.
The future
It’s easy to fall into the trap of thinking that we know what the future will look like. We know that we will need to add more functionality, so why not do it now. It seems easier to do it now when the code is fresh and still pliable for changes than to wait when the feature request will come.
But it’s a fallacy. We think we know exactly what the future will bring. We think we can build something which will save us work.
I’ve seen a lot of times when a solution was over-engineered, prepared for the upcoming requirements. Requirements which never come. It was a great solution to the non-existing problem. And that code wasn’t free, it wasn’t just unused. It caused problems.
Of course, I also have seen cases when solution build for future did save the time when it worked out perfectly. I would argue that this was an exception, something we should not depend on. It’s like with winning a lottery. There’s nothing wrong when it happens, but if you start to depend on you will quickly be in trouble.
What’s wrong with predicting the future?
First and foremost, it’s an impossible task. It’s not very hard. It doesn’t require trying harder. It’s not possible to predict what the future will bring.
Yes, you can have clues and know where the project is going. It may even be true in the longer term. You may have the list of the tickets ready for the implementation and if your very next ticket will benefit from the work you can do now, go ahead and do it.
But in the long term, you don’t know where the project is going. The environment in which the software operates, the businesses around it, constantly changes.
Why is building something you don’t need bad?
First, you are building something without having full requirements. Of course, you have a pretty good idea what they will be, but it’s still a guess, an estimate. You will get something done, but not necessary the thing which will be needed in the future.
You are making the software more rigid, less changeable. That’s because all that code to implement future requirement needs to be tested, needs to be maintained and kept up to date. And it needs to integrate with the existing code which means changes to it. It will require time, time which could be spent on working on the current problem or improving the already existing code.
You feel that doing it later will not be possible. That your ability to code a solution now is the best, so why not do it. If you have a brilliant idea to solve the current and future problem, write it down. It will help when the time comes.
But if you are afraid that you will not be able to solve the future problem then you are wrong. Tomorrow you will know more about the system, about the requirements and about programming in general. You from tomorrow will be better equipped to handle this problem.
Solution to YAGNI
Instead of trying to predict the future and build appropriate code to handle everything will go much better to prepare. To create flexible solutions. Solutions which are unencumbered by unnecessary code and by unnecessary complexity. That way when the change arrives you will be in a much better position to actually implement it.
Remember: the most flexible code is the one which is not yet written.
I’m not advocating of building the bare minimum to pass the current requirements. Rather be prepared that those requirements change and to ensure that any solution implemented today will be adoptable to the requirements of tomorrow, whatever they will be.