How to avoid over-engineering

It’s easy to get carried away with your ideas and end up with an unnecessarily complex, large piece of code. Then you look at it and marvel at the beauty of what you produced while others dread the possibility of having to maintain it in the future.

After it goes into production and some time passes, you realize a big chunk of what it was prepared to do didn’t materialize and never will. You’re forced to reconcile you could have solved the problem in a much shorter time, writing way less code, with a lot less complexity.

We’re all guilty of this crime at some point, and there’s always the risk of receding. We all have a blind spot when it comes to our work; it’s as normal as it’s terrible.

Over time I developed a series of safeguards to prevent falling into this trap again, and I’d like to share them with you.

The first is to pitch it to other engineers and pay attention to their reactions. If you’re excited about it, but nobody else is, don’t stop until you understand why not. Most people don’t want to rain on other people’s parade, so you might need to insist until they tell you.

Don’t dismiss what you hear from others, sleep over the feedback, and advocate on their behalf with yourself. Remember you’re not trying to win, you’re trying to pick the best solution.

The second is to second-guess everything you assumed. Ask yourself:

• Is the problem important enough?
• Isn’t there a more straightforward way?
• Will it be easy to maintain?
• How much time will someone need to pick it up?

Finally, remove all unrequired flexibility from it. I know you think it’s a good idea but, trust me on this, YAGNI.

There’s a good chance it will never need to be extended, but even if it happens, you’re probably picking the wrong part to make flexible.

You cannot predict the future, don’t make things harder to prepare for what you think will happen. It likely won’t.