This is so true, and has been forever. In the early 90s I worked on a system where you couldn't just write structs, rather you had to submit their definition to a guy who entered the details into a database, and there was a daily run to generate the C header files from that database. To this day I'm convinced the only reason it was done this way was that it could be done this way.

It's an over-reliance on ceremony. On some days I think it's a character trait.

Ouch! Crazy ;-)

> When you put engineers in charge you get overengineering

This means you picked the wrong engineers. An engineer's job and skill is to be able to make this sort of call.

The same goes with managers or any other role.

So the way out is always to carefully select experienced, competent, no nonsense people.

Getting experienced senior engineers, probably they have seen both; and in the best case they have worked on a middle ground project so they experienced how to do it and how not to do it.

I think you need to have a few of those "I've use this pattern and had to stay up 24 hours to meet a deadline because shit was way too complicated for the delivered value" to instil a healthy fear of overcomplicating solutions.

I've worked with developers with 5+ years of experience that haven't went trough that (either corporate culture allowed them to deliver minimum value in 5 days or jumping projects before it gets to the WTF stage of complexity). It's hard to learn if you never get burned.

Experienced and exposed to areas outside their main expertise so they are well rounded and pragmatic.

At the moment, there's no way out, plannign stipulates that all our microservices must be rewritten to accomodate this super abstract DDD design (and youy're right, it was an engineer who created our current layout)

> When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?

The whole idea is to bring them together "in the same room" and allow common understanding of the domain so they stay on the same page throughout the project. Then they'll do each what they are best at (managers whip up glossy slides, and devs crank out reams of code ;)