"Legacy code" is often code that you want to replace because you don't understand it. The problem is, before you can replace it, you need to understand it, and, once you understand it, replacing it is rarely the cheapest option any more.
[#]SoftwareEngineering
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru When I've replaced legacy code, half the time I should have fixed it instead; and when I've fixed legacy code, half the time I should have replaced it. (In both cases, adding tests of course).
If I had made the opposite decisions, I probably would have concluded that I was mistaken the same 50-50.
Bad code is like a cancer - all remedies are bad and it's a matter of guessing the least bad cure. (And the author of the bad code probably got promoted before the effects of that code manifested.)
PS: bad design is even more problematic.
=> More informations about this toot | More toots from PeterLudemann@mathstodon.xyz
@PeterLudemann I agree. That's why I advocate to bias toward fixing in-place: in one scenario, that's the right thing to do even though you're not initially sure, in the other scenario, you end up learning from the code you're going to replace so the replacement does a better job. If you write the replacement without benefiting from the experience embodied in the existing code, you're starting from the same place as the people who wrote the original code, and you'll get a similarly bad result.
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru
I once had to deploy some code at a customer and, after reading some of the code, I strongly suspected that it wouldn't scale as-is. I rewrote the code in ~6 weeks -- I later found out that the original took ~6 months to write. (I didn't write code faster; I just wrote a lot less code and didn't over-engineer). I'm ~90% sure that fixing the existing code would have taken longer (it would certainly have been more painful).
I agree that "legacy" code often contains fixes for special situations that were encountered, and aren't well-documented -- this is especially true of business logic. But over time, code also accumulates useless barnacles and at some point needs to be scraped clean -- as a rough rule of thumb, after 5 years, if the code is still needed (and often, it isn't), it should be redesigned and replaced (and beware of "2nd system effect").
=> More informations about this toot | More toots from PeterLudemann@mathstodon.xyz This content has been proxied by September (3851b).Proxy Information
text/gemini