Unfortunately until crappy and slow performing software starts losing business to well-implemented alternatives, it will never change. The current PM model is purely based on shipping fast, and any thought to performance is immediately dismissed as "pre-mature optimization." I've been consulting for companies that had to rolling reboot their entire cluster of app servers every couple of hours because a host of memory leaks (that also added O(n) runtime) would slowly exhaust resources. Rather than have someone fix the problem, they chose to invest in devops to automate the rolling restarts. This is not all that unusual in my experience, because customers will tolerate very sluggish response times so it's not worth fixing to the business.
Entirely my experience. I worked for a very large company and since our microservices were running in Kubernetes it was totally OK for the services to crash. We just logged the things in elastic stack, used data dog to monitor, used some SRE to restart services when things were messy.
I've lost days to solve a memory bug in one of the services and no one cared.
The original architect and programmers were gone, the engineering managers were pushing Clean, SOLID and design patterns hopping that will help and the domain was hard because we had to deal with real money while respecting tens of different laws and locales.
We tried at our best to do the impossible, we were understaffed by a factor of 5X.
And the services were crashing like crazy but it looked like a no downtime because we provisioned another POD in Kubernetes.
Provisioning was like: how many pods do we need? 3? Let's make it nine. How much memory do we need? Half a gig? Let's make it 4 gig to be sure.
So it was a mess and it worked and that mess continues to work somehow.
Not sure if mess driving engineering is a sound bussineses idea, though.
Erlang has taken 'let it crash' to entirely new heights, but that's from a top level viewpoint, components are allowed to crash but the service isn't. And you're still supposed to figure out why your service crashed but I'm pretty sure not everybody does that.
So as long as your supervision mechanism is bulletproof (supervision trees) then you can get away with this for very long.
