"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 I've found the difference between inexperienced and experienced developers is how they respond when they see a massive legacy system.
I have a 20yr old erp system that my new client's CTO wants to completely rebuild - in one year. I was like, "dude, I wrote that in 2003 and have been actively adding to it for 20yrs. There's a lot going on there that you don't see"
I told him he could feel free to rebuild it on his own with his own team of developers. So, that's what he's doing. He started last January. It's about 10% done and that 10% doesn't work and I can already see that it will never work due to a base design decisions they made from the get go.
But, it's one of those things that people just have to learn from their own failures.
=> More informations about this toot | More toots from coldfish@sfba.social
@coldfish At a previous job, we had a 2Mloc codebase, with 200 active engineers working on it. Upper management was advocating that we rewrite it. I argued that, at that scale (and we had historical evidence for it), each engineer adds about 2kloc per year, so it'd take 5 years to rewrite. I asked whether we could afford to go 5 years without new features, and then to put code in production in 5 years that would have been written 5 years before, by people who'll have left. I won the argument.
=> More informations about this toot | More toots from jbqueru@fosstodon.org
text/geminiThis content has been proxied by September (ba2dc).