The "Engineer A vs. Engineer B" scenario where B gets promoted for overengineering glosses over the fact that A would be delivering features much faster - you really think that would not get noticed?

I think overengineering leading to promotions can only happen in organizations so large that engineering managers are isolated from business impact considerations, because that is usually the overarching metric.

Because unfortunately, someone proposing simplicity somehow means that it threatens another person's job security, which is quite frankly pathetic, even though it can lead to saving the business money and time.

The only valid excuse is whether the risk is worth it vs the potential gains. But the solutions that I prefer are the ones that offer minimal changes with massive gains rather than co-ordinating with hundreds of teams for years over an unrelated change.

If you have to do the latter for a tiny code change, then the architecture was most certainly built on a bad foundation, riddled with hundreds of brittle moving part waiting for an incident.

[dead]