2 ms·

and what better way to spark joy on the new team than the opportunity to leave all the tech debt behind with a clean rewrite (in rust!) only half joking.

KronisLV 2y ago
Regardless of the language or the trendy tech used, people seem to enjoy doing rewrites way more than working with old codebases, especially if their new solution doesn't need to be 1:1 with the old one and therefore they can justify no longer needing to work around certain edge cases. That longing can't really be helped, though. 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.
- 8n4vidtmkvmk 2y ago
  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.

KronisLV 2y ago

Regardless of the language or the trendy tech used, people seem to enjoy doing rewrites way more than working with old codebases, especially if their new solution doesn't need to be 1:1 with the old one and therefore they can justify no longer needing to work around certain edge cases. That longing can't really be helped, though. 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.

8n4vidtmkvmk 2y ago
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.