"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 @squads I'd like to have this printed on a t-shirt I can wear to every sales conversation where a prospect comes to us to rewrite, and I want to sell them testing first.
=> More informations about this toot | More toots from iwein@mas.to
@iwein @jbqueru This would definitely make a great conversation starter!
Testing first sounds like a solid approach but here is my question;
How often do clients realize the value of understanding their legacy code before jumping to rewrite it?
=> More informations about this toot | More toots from squads@mas.to
@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.
@jbqueru
=> More informations about this toot | More toots from iwein@mas.to
@iwein @jbqueru why is it that new generation of devs doesn't want to touch the legacy?
... just according to you?
=> More informations about this toot | More toots from squads@mas.to
@squads sorry I was unclear. It's not a younger generation, but the people who came into the company later. I myself have advocated for a rewrite when joining a new company 😅
@jbqueru
=> More informations about this toot | More toots from iwein@mas.to
@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 🤣
@jbqueru
=> More informations about this toot | More toots from iwein@mas.to
@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?
=> More informations about this toot | More toots from arclight@oldbytes.space
@iwein @squads@mas.to 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...
=> More informations about this toot | More toots from jbqueru@fosstodon.org This content has been proxied by September (ba2dc).Proxy Information
text/gemini