3 ms·
In my experience, most rewrites fall more into the realm of "it's easier to write code than it is to read it, and I don't want to read all this existing stuff!"
by overgard 3mo ago
In my experience, most rewrites fall more into the realm of "it's easier to write code than it is to read it, and I don't want to read all this existing stuff!" That's kind of the fundamental motivation, and then people couch it in some very plausible sounding technical reasons. (I don't even think people are being dishonest when this happens -- it's easy to look at a codebase and think "this sucks!" because you don't understand the context behind the original decisions.. and writing new code is a lot more fun than maintaining old code) I'm not saying "never rewrite" things, there are valid cases where the original tech stack is no longer relevant or the accumulated tech debt really is too much, but I'm pretty skeptical of most rewrites at this point in my career.
- Pannoniae 3mo agoWell yeah, for example I'm working on a codebase written mostly in 2003. The assumptions in the original code are at best tangentially relevant (stuff like "LUTs are cheaper than using ALU" or "CPU power is cheap, GPU power is very expensive"). Despite that, a grand rewrite would have failed massively (even with agents...), replicating millions of lines of code to be functional again just sounds like an absolute nightmare. So I've been doing "targeted rewrites" instead - not sure, there's maybe a name for it? Basically do it concern by concern, module by module, so even if lots of code was touched, it only affects one logical feature at the same time.