In my head, I've started to understand the suck in terms of timescales. Leaving products that are too complicated for the people who build it aside, even if you have the most competent and well-oiled team onboard, there are two things that together guarantee their output will suck:

- Usually, the "right way" to do something is only apparent halfway through doing that thing, or after you finished that thing.

- There's rarely time to redo things with benefit of hindsight, because the priority is always to work on business goals first.

That's how things were everywhere I worked or seen, so I believe this is likely a general phenomenon. But the consequence of that is strong path dependence. It's not that using Kubernetes makes you a moron or a smart person. It's that somebody already deployed Kubernetes for a project that's too simple for it (or they were too inexperienced), but business pressure makes it impossible to spend a couple of weeks undoing it, so everyone is stuck with the pain. Perhaps the reason for the initial Kubernetes deployment was because it was the fastest way to fix some other issue, and the company could not allocate enough time for engineers to do it right.

To be clear, this isn't me ranting about "stupid managers with their priorities". Pursuing business goals is the raison d'être of a software company (it's pretty much a tautology). I'm just saying, it's hard to improve things without lots of slack, and slack is a competitive disadvantage.

Perhaps another facet to this is: business lifecycle is too short for software lifecycle. If you were to spend time on redoing things properly, by the time you were done, you'd be out of business.