I love coming back to a feature that was developed a couple of months ago and seeing that extending it is just a walk in a park. When thinking about a solution, I always ask myself the same question: If I were to change this in a month, how hard would it be?

I find it a great way to catch flaws in my solutions very early, but it can also lead to something called overengineering. To put it simple, overengineering is the act of solving a problem that doesn’t exist anywhere besides your mind.

Overengineering leads to bad code

It took me a long time to realize that even though my code is nice, clean and easy to extend, it is still a bad code. It often introduces unnecessary complexity, being harder to maintain and harder to understand by other devs, while taking a longer time to build.

None of it is a bad thing by itself. If you were to code just to get it done, you can get by, but in a month all you would get is messy, spaghetti code that nobody wants to work with in the future. It becomes a bad thing when that price is paid for a feature that you really don’t need.

Do you actually need it?

I’m still fighting this battle myself and the thing that is helping me is a principle of extreme programming (XP) called “You ain’t gonna need it” (or simply, YAGNI). XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them.”

Now, whenever I start overthinking and catch myself wondering “But what if X happens” I just stop and write down my what ifs. Also, I think about what would happen if that feature is not implemented. Is the added complexity the price I’m willing to pay just now?

Making that call is not easy

It is important to differ what is needed and what is not, even though it is difficult to do that. If that is a decision you are having problems with, ask your teammates. A fresh look at the problem is something that always helps. If for whatever reason that is not possible, go with a simpler solution. Keep the list of what ifs and if they actually happen, choose the more complex solution.

This approach helped me with decision making paralysis and I believe it also made me a better developer.

How about you? Do you also sometimes overengineer? What are your tips and tricks for deciding what is needed and what is not?