Re:Making a system highly available isn't just about adding ...
by 8n4vidtmkvmk on Wednesday February 26, 2025 @11:23PM
(#43191339)
It always goes wrong. I've done it like 3 times now. Migrated from one language to another, and then it was taking too long so we rushed it (and also no one was proficient in the new language), so it became an utter mess. So now (3 years later) we're spending another year un-effing it (or trying to). Another one we switched data backends which yielded no performance benefits nor new features and was also rushed. And the 3rd was mostly fine (because it was small) except that it was deprecated like 6 months later because of another mandatory migration. Millions of dollars just wasted writing and rewriting things with little to no benefit.
Honestly, as long as the second system effect doesn't ruin everything and you still make the new codebase better than the old one (i.e. it's small enough to actually be rewritten and testable enough to make sure that it actually works, with the abstractions that you now know you need and have solidified enough to be the right ones, without too strict deadlines and only as much backwards compatibility needed as you can provide, as well as buyin from whoever is paying you), then unironically go for it.
That's way fewer projects out there than people probably think. Plus, a lot of the wrongly started rewrites will go up in flames. Oh and it's probably also going to go wrong if people don't actually know the new language or tech.