@"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.
iwein
Squads@squads
It's more subtle than that usually. Typically, the clients are convinced they do understand the legacy code, but in fact they don't.
Usually a new generation of devs doesn't want to touch the legacy, and a prior generation is too overworked to explain all the intricate workarounds and existing processes that keep the whole mess (sort of) functional.
Almost always there are no clear repeatable regression tests (anymore).
Solving that first surfaces the real challenges.
@squads
Diving into a legacy code base of a company above a certain size and age is one of the most painful things we as developers have to endure regularly. The easy way out (for us) is to just start from scratch, but this is almost never the best option for the shareholders of said company.
That's why we charge so much money to do this dirty job: it's actually worth it.
And some very lucky few of us, the menders of our trade, we actually enjoy the pain of working with legacy 🤣
arclight@iwein @squads @jbqueru Honestly, I'd be a lot happier revitalizing old but perfectly Fortran than trying to keep up with the infrastructure and fashion hell that is Python. I put in the effort to understand the limitations that previous generations of devs were working around - resources, language features, state of knowledge, etc. - as well as the idioms of their workarounds. Often the underlying engineering or science embodied by these codes is still relevant and sound and the codes themselves have been used long enough that most of the frequent bugs are gone. Most legacy code I see isn't bad, it's just inconvenient and few want to put in (or pay for) the effort to refactor and modernize. If there's no money to maintain the existing code, why does anyone believe there will be money to rewrite, re-debug, and document a new code _and_ ensure it will be maintained so we're not going through this same nonsense again in 10-40 years?
@iwein @[email protected] The way I see it, it's a matter of experience, but specifically of experience relative to the code in question. Obviously, folks without enough absolute experience also won't have the necessary relative experience, but it's easy to have plenty of experience in other domains and still to be stumped by a piece of code we've never seen, written in a language we don't know, on an OS we don't use, with libraries we're not familiar with...