I bet anyone who’s been in this industry for some time has experience with an over-engineered solution, be it seeing it from the outside or, most likely, building it. I know I have.

For years I have thought of this as a purely technical problem: the engineer (me) has got carried away with a solution more technically challenging and fulfilling than what the problem demanded. As a purely technical problem, the responsibility lies on the technical people and it's on them to avoid it.

Lately, I realised that by treating this as a technical-only problem we are ignoring a big cause for it, and thus, allowing it to happen again and again.

In my experience over-engineering tends to happen in two different environments: one is where people without enough experience, without enough failures, make long-term decisions. That is a purely technical problem that the technical team needs to address (and I’m not focusing in this article); the second environment where over-engineering tends to happen, and it’s usually ignored, is where maintainability, refactoring and design are not allowed to occur in a regular basis.

If you are building a new feature or a new system and you feel you need to hurry because a product manager may be pressuring you to create value for customers if you feel you won’t get more time in the near future to change the design to address new requirements if you feel this is your only chance to really do proper design and develop with good practices, chances are that the solution will be over-engineered because you will be trying to solve all possible requirements you can imagine so this solution really scales and in reality you will be solving lots of problems you will never, making the solution unscalable.

If that has ever happened to you, or maybe it’s happening right now, please know that it’s not your fault. It’s not the fault of the product manager either. But I think both are part of the problem. The product manager should understand and support continuous refactoring as requirements change and things are learned and engineers should understand that we are not capable of solving big complex problems in one go and that we are better off building something simple and iterating over it.

Closing thoughts

Over-engineering is something that can’t be fully avoided, we are all humans, we all get carried away sometimes, and we all make mistakes. Nonetheless, I have found that asking myself (and my team) whether we are solving a problem we don’t have yet and whether we are attempting to optimise something too soon without really knowing if it’s needed is a very useful tool to keep our engineering minds from going too far.