[qsort]

I wouldn't say that "over-engineering means solving the wrong problem". It's possible that the idea is basically correct, but people are directing effort towards optimizing for constraints that don't really exist or can be dealt with once a better picture is in place, whether it's the mythical PMF or just "we now understand what the users want, let's build that".

The worst clusterfuck I've ever worked on was a web application that was actually solving a real problem fairly well, but the team was spending time building an absurd Rube-Goldberg contraption of microservices when the entire platform had less MAU than my hobby website. It wasn't the wrong problem, but it certainly was over-engineered!

[var0xyz]

> but the team was spending time building an absurd Rube-Goldberg contraption of microservices

This is literally the example that I use, the most common case of over-engineering, having more microservices than team members. Microservices are the right solution for certain problems, but those were not problems they had.

Some anecdotal evidence. I worked in many of these places, and the most common tell of over-engineering is that when you ask "what problem were we solving when we decided to have all these many microservices?" the answers you will get is problems they either didn't have (for example, high availability) or they state a problem they actually had but could have been solved in the monolith.

In other words, they "overshoot" and - as I write in the post - end up with "a system that solves multiple problems partially, none of them completely, while introducing a bunch of problems you wouldn't have had otherwise."

[win311fwg]

> Microservices are the right solution for certain problems

Just one problem, actually: Conway's law.

When your organization needs to operate like the macro economy, where independent groups provide services for each other, then you are going to see the same structure found in the macro economy mirrored in the microcosm of that single organization. Hence the name microservices. Same as services, except not across business lines.

At Google scale you have no choice but to have an internal economy, but trying to build an entire economy inside a small business with less activity than a personal blog is crazy.

[xnx]

> more microservices than team members

Or more microservices than customers

[zephen]

You need to be careful with this one, or reductio ad absurdum might lead you to not build microservices, or even a monolithic app, before you have acquired your first customer.

[xnx]

True, but also "Do Things that Don't Scale" (https://www.paulgraham.com/ds.html). There are many examples of successful companies that had customers before they had products.

[estetlinus]

> absurd Rube-Goldberg contraption of microservices

Such a lovely analogy. FYI it’s mine now.

[godelski]

While I agree with you, a large number of people use the term to mean that something was engineered to a complexity they have difficulty understanding. Abstraction is also treated as a dirty word, with people focusing on only one interpretation of the word.

While I don't actually agree with OP, I do agree with their sentiment. I've seen people say something is "over engineered" when there's an elegant design. Elegance isn't over engineering, it is solving problems effectively. It's something we should chase! Elegance is solving the right problem, which usually people are having a hard time seeing. (It's not always easy)

If we constantly let people drag quality down then we get into this frustrating world where everything is constantly half broken.

[bluefirebrand]

> optimizing for constraints that don't really exist or can be dealt with once a better picture is in place

I think these both fall comfortable under the umbrella of "solving the wrong problem"

[kccqzy]

And sometimes optimizing for constraints happen because someone from above (perhaps someone with a title of Director who doesn’t actually write code) imposed their constraints on the team without understanding the ramification of these constraints. It takes a manager with very good people skills and/or very good writing skills to persuade that someone to drop their constraints.