Steady State Means Continuous Rewriting

I wonder _why_ it is that 50% of the initial team has left within 3-5 years? Could it be that continuous rewrites and ever-shifting tech stacks is a symptom / the "pound of cure" to the problem created by companies not valuing employee retention & growth (ex: non-least-effort employee training, paying employees proper market adjustments...if HR has budget for a rando off the street to get paid market rates...why not your existing employees who you will lose anyways if you don't pro-actively adjust their pay, AKA the "ounce of prevention").

EDIT: if your company's addiction is to rewrite, like all addictions, it is serving a need. How can you lessen the cause of that need? One major way would be good (defined at present as likely 'industry leading') employee retention.

Just imagine what would happen if your house building projects changed all general contractors and most subcontractors every 2 weeks? It would be chaos and you would end up with an over-expensive pretzel. Why we think software programs are different is beyond me.

A company that has no long-term strategic goals isn't in a steady state. It's in run-off mode.

Anyone can come up with a great strategy or grand plans for the future of the company. But it's really, really hard to figure out how to go from "where we are now" to "where we want to be".

Making big changes to your systems to enable that transition without disruption to the current products and processes is actually a really difficult thing. If you could pull it off, it would most likely appear to be continuous rewriting with minimal visible changes ;)

I'm just surprised people can find developers to do these rewrites. I've never worked on a system I could recreate and I'm pretty wary of trying it even with code I wrote myself. There are just so many pitfalls and details. I trust almost any dev I've worked with to edit an existing system, but almost none of them to write new code.