This one will be short.
Yesterday, while I was browsing a programming forum, I came across a statement like this:
“… and currently, I am creating some neat abstractions if I need something more in the future…”.
This is so wrong! And let me tell you why.
Overengineering
Overengineering in software development means creating something that is not needed. Something that brings overhead to the development process and inefficiency to the end product.
An elementary example of overengineering is if all your applications data can be saved in a 10 line XML file, but you use a SQL database.
Predicting the future
One of the reasons overengineering happens is because of a lack of information.
Often developers want to predict the future, so they are ready when new requirements come, or requirements change.
The practice and statistics show that they are tragically bad at that.
In fact, even business people don’t know how requirements will change.
That’s why agile methodologies were born.
In the modern world of software development, it often happens during one sprint to create functionality, and in the next one, to change it so drastically that it is better to start all over again.
Do you believe that you will have the right estimate and create the right thing from the first time with all this uncertainty and change? I believe not.
Predicting the future is a waste of resources, so don’t do it.
Inexperienced developers
Inexperienced developers tend to create overengineered things by default 😊. And that’s is normal for their level.
They do it mainly because of two reasons.
1) They want to create something complicated and “cool”, trying new practices, patterns, and technologies.
2) They don’t see a simple way of doing it.
Only gaining experience can solve the second one, but inexperienced developers should intentionally avoid the first one.
Don’t get me wrong. New things should be tested, but not directly on paying customer’s projects.
