No, this isn’t over-complicated, it’s just complicated

There’s been a few times in my career where someone called my work “over-complicated”, usually behind my back. The first time I heard this, I spent days wondering if they were right. One day I would think about it and get annoyed, and the next day I would convince myself they were right and lean into my imposter syndrome.

But as I gained more experience, my thoughts on that phrase became more clear. I started noticing a pattern whenever someone called something “over-complicated” or “over-engineered”. I realized that many of the times you hear this phrase, it’s from someone who has not given the problem and all its subproblems very much thought.

“Why are we over-complicating this?” is a very easy thing to say after being introduced to a project. What’s hard is to reserve judgement until you’ve educated yourself on the entire problem domain, and noted all the considerations that were made by previous developers.

Consider the below diagram:

My theory is that when most people say “over-complicated” they think they’re in the top-left (Complex Solution, Simple Problem) of the diagram, but really they’re in the top-right (Complex Solution, Complex Problem) or even the bottom-right (Complex Problem, Simple Solution). They just haven’t spent enough time thinking about the problem or solution to realize which quadrant applies.

It’s a trap in software engineering to hastily assume a problem is simple that in reality is much more complex. If you take a complex problem, assume it’s simple, and try to apply a naive solution, then you end up with a low quality solution that does not fully solve the problem. You also risk straining relationships with developers around you who have already put a great deal of thought into all the aspects of the problem.

That said, I think we’re all striving for simple solutions to complex problems. But often this is hard to do and requires more than surface level thought. And then you tack on the business pressure to ship and it’s even more difficult. Additionally, solutions that are simple relative to the complexity of the problem can still appear over-complicated at first glance if one is under-estimating the complexity of the problem.

I’m not saying to never call something over-complicated. What I’m saying is that before one jumps to declaring something over-complicated, they should take care to consider the entire problem domain and all the subproblems. If you’re onboarding onto a project with existing developers, ask questions and try to understand all the considerations made by the people before you.

Nowadays, I cringe whenever I hear someone call something over-complicated before trying to fully understand it.

Edit:

After some feedback on this article, I want to make it clear that the above should not be used as an excuse to be content with complexity. Nobody should be happy with complexity. All this article is advocating for is that:

1. Complex problems exist. That’s just a fact.

2. Simple solutions to complex problems are hard, take time, and business pressure to ship doesn’t help. I’m sure no reader can reasonably claim they’ve quickly shipped a simple solution to every complex problem they’ve run into.

3. Do not judge a solution as “over-complicated” until you fully understand the problem domain and every sub-problem that the business needs to be solved. For example, often the business wants some or all of: accessibility (sometimes legally required), good UX, good performance, mobile responsiveness, consistent visual design, maintainability, etc.

   After you have an understanding of the entire problem domain, that’s when you can reasonably call something “over-complicated”. Or maybe you’ll realize the solution is already simple relative to the complexity of the problem. Or maybe you’ll realize both the problem and solution are complex, and you’ll be better equipped to help make the solution simpler.

Edit 2:

I also agree with feedback that before coding we should be asking the business if the requirements can be made simpler without compromising the business goals. This article is specifically referring to problems that are still complex after asking the business those questions.

Edit 3: Found the obligatory XKCD: