Let me tell you a story.
Imagine that you are working on your application and you need to implement a very important feature. Like any engineer who loves his trade, your mind explodes with multiple ideas how can you make it better.
You brew some ideas, add some improvements, spent twice as much time as you should, but…
Your code is amazing!
- It can support 10x the load that your app is getting now.
- The feature has all the bells and whistles that you could think of.
- It is as future proof as you could fathom.
You thought of every possibility, except for one:
Two months later the business needs have changed, and your shiny new code is no longer needed.
Your perfect solution goes to the infamous feature graveyard.
So you have spent the extra time for something you didn’t yet need, nor you ever will. Is it a far-fetched scenario? Experience teaches us otherwise.
There are two acronyms that you should adopt:
YAGNI - You Aren’t Gonna Need It
Don’t implement something you need not do now, since you probably won’t need it later.
It doesn’t mean you should compromise on generating technical debt. Do what you need for your business needs.
Example: When building an email notification system that needs to send simple text messages, you shouldn’t implement a dynamic HTML formatter with complex templates, just in case, since you “might need it later”.
KISS - Keep It Stupid Simple
Do not overcomplicate things. Simpler solutions take less time to develop, less time to debug and simpler to maintain.
Example: When developing a functionality that would check existence of a file in a certain path, you probably should write a simple function instead of engineering a class hierarchy that would allow you to extend to support for other file systems.
As you can see, it strongly correlates with the YAGNI principle.
I’ve been there multiple times and failed too often for my liking. That makes me an expert. Pay attention!