"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 agreed
=> More informations about this toot | More toots from usul@piaille.fr
@jbqueru well said
=> More informations about this toot | More toots from ireneista@irenes.space
@jbqueru
On occasion, you open up legacy code and discover the backdoor that an overseas contractor buried in some obscure corner.
Foiling a hack, ransomware, & a lawsuit settlement rarely gets the public acknowledgement that it should.
Most senior managers slap an NDA on it and memory hole it as quickly as possible.
Then stick you with the task of shadowing all code commits as punishment. Lol.
=> More informations about this toot | More toots from Npars01@mstdn.social
@jbqueru
Q.V.: Chesterton's gate/fence
https://fs.blog/chestertons-fence/
=> More informations about this toot | More toots from n_dimension@infosec.exchange
@n_dimension @jbqueru There's an excellent bit of wisdom in “Do not remove a fence until you know why it was put up in the first place.”
It's so apt for fences, legacy code, and regulations. None of these things spring up just for fun, yet too often there is a rush to discount the blood, sweat, and tears that went into them because the problem that they're alleviating is no longer apparent.
=> More informations about this toot | More toots from dotjayne@tech.lgbt
@dotjayne @jbqueru
Kinda obliquely related.
But it's such a sweet story, and it was well conveyed by Peter Jurasik, that I retell it whenever the slightest excuse arises.
Lando Mollari, an imperial Ambassador of the ancient and failing star Centari empire in "Babylon 5", tells a parable.
Of a child princess, who saw a tiny, pretty flower spring from between the stones of the parade ground.
Fearing it would get trampled by the troops, she placed a soldier to stand guard over the flower.
Years have passed.
The flower is long gone.
The princess is long gone.
The guard still stands there, in what seems to be a random spot on this huge parade square.
You can choose to look at it as a tale of bloody mindedness.
I, like Lando, think it's a beautiful tale of how purpose and order still prevails long after the need had gone.
[#]babylon5
=> More informations about this toot | More toots from n_dimension@infosec.exchange
@n_dimension @dotjayne @jbqueru lovely.
Of course in IT we have a workaround as such. it's not pretty. I've generally heard it called "see who screams".
That is, in a working system, if the gate (or the guard) is of use, someone will probably notice if it is removed and tell you why it was needed; if so, you can put it back.
In my experience this works well about 70% of the time. The other 30% of the time it's a ticking timebomb…
=> More informations about this toot | More toots from fishidwardrobe@social.tchncs.de
@fishidwardrobe @n_dimension @dotjayne Oh, I love scream tests, and I've done quite a few for those scenarios where you're not sure yet that something can be deleted.
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru @fishidwardrobe @dotjayne
...and you get to look like a hero for "restoring" the service.
😁
=> More informations about this toot | More toots from n_dimension@infosec.exchange
@jbqueru @n_dimension @dotjayne I can never work out whether I love them or not. I've multiple times had cause to think, after the shit has hit the fan, "ohhhhh. THAT'S what that was for…"
=> More informations about this toot | More toots from fishidwardrobe@social.tchncs.de
@fishidwardrobe @n_dimension @dotjayne As a leader, I've internalized that my job mostly involves making choices between options I don't like, in situations where there's not enough information. I don't get to say that we shouldn't have ended up in such a bad situation.
A scream test is a great way to clarify how much I should dislike deleting that code, to gather information that allows me to move forward. So, I love them.
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru @fishidwardrobe @dotjayne
"Scream Tests, a more exciting alternative to boring documentation"
~ Wulfy
=> More informations about this toot | More toots from n_dimension@infosec.exchange
@jbqueru Perhaps, but now you understand it and have documented and commented it, so it's no longer a mystery.
=> More informations about this toot | More toots from KatS@chaosfem.tw
@jbqueru Depends on code quality, I guess?
Sometimes, the code is bad enough so you really want to replace it. Except if you consider "running away screaming" or "going into the woods chopping down a tree" as the cheaper option 😉
=> More informations about this toot | More toots from genodeftest@digitalcourage.social
@jbqueru So true.
=> More informations about this toot | More toots from tsturm@famichiki.jp
@jbqueru well put, and that definitely rings true with past experiences
=> More informations about this toot | More toots from dandelionmood@piaille.fr
@jbqueru @ireneista sometimes, though, understanding can only harden your determination that the legacy code must die.
like a custom build "system" for a java project written in a clusterfuck of perl scripts. porting to java required understanding, but the result was a couple of orders of magnitude faster. then replacing the whole damn thing with gradle
=> More informations about this toot | More toots from StrangeNoises@mastodon.social
@jbqueru Seems like these days "legacy" means "not written in rust" to some folk.
=> More informations about this toot | More toots from mos_8502@studio8502.ca
@jbqueru Can I quote you on that?
=> More informations about this toot | More toots from drwho@hackers.town
@drwho Absolutely :)
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru Thank you kindly!
=> More informations about this toot | More toots from drwho@hackers.town
@jbqueru I have heard it said that legacy code is code without tests. There are people pumping out legacy code right now
=> More informations about this toot | More toots from flyingsaceur@ioc.exchange
@flyingsaceur @jbqueru I fondly remember @samir saying after one of my Code Dojos "Now I see how people can write legacy software in twenty minutes!"
=> More informations about this toot | More toots from sleepyfox@hachyderm.io
@sleepyfox @flyingsaceur @samir Yup. Legacy code is code for which the maintainers don't have enough understanding, and tests embody that understanding. So, indeed, it's possible to write code without thinking much about it, and, without test or documentation or comments, the knowledge fades away in extremely little time.
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru @flyingsaceur @samir I personally don't completely agree with Feather's simplistic definition, the truth is more multifaceted.
But code without tests is probably on the way to becoming legacy code, yes.
=> More informations about this toot | More toots from sleepyfox@hachyderm.io
@sleepyfox @jbqueru @flyingsaceur I also have fond memories of that workshop. 😁
And I agree that “code without tests” is an interesting category of legacy code, but not even close to all of it. I have seen so much code with comprehensive test suites that was full of bugs and completely unmaintainable.
=> More informations about this toot | More toots from samir@functional.computer
@jbqueru Word!
=> More informations about this toot | More toots from StompyRobot@mastodon.gamedev.place
@jbqueru I find Claude does a pretty good job of code explaining
Problem ofc is that most employers' code is NDA & not OK to paste into an AI
=> More informations about this toot | More toots from dragonsidedd@sciencemastodon.com
@jbqueru Also, "legacy code" gets janky looking because it's seen the elephant. Those ugly fixes in there? Those are BATTLE SCARS. 12 months after release, your perfect architectural vision will look like that too!
=> More informations about this toot | More toots from lerxst@az.social
@lerxst Exactly. It fought a battle, and it survived. Even if some of those fixes are now unnecessary and you have no way to determine that, maintaining those fixes is less costly than having to re-build all the non-obvious fixes that are still necessary.
Worse, if you rush a re-implementation, you're at risk of having something worse than what you're replacing.
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru But when it breaks, and it will break, ya gotta be able to fix the functionality.
=> More informations about this toot | More toots from avirr@sfba.social
@jbqueru "cheap" is only one aspect...being able to maintain such code is often a nightmare. A radical cut is often the best option. Code that is no longer maintained is problematic code, in particular if without documentation and tests. Legacy code is often a blocker for evolution.
=> More informations about this toot | More toots from zopyx@mastodon.world
@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
@jbqueru that’s a key insight I have from 30 years professional engineering and engineering leadership experience. As much as genuine tech debt is generated by scrambling to meet business objectives, there’s also this fictional tech debt caused “this is not my code, it’s rather rewrite it than understand it”. Often attempts to fix the fictional debt go unfinished because or are buggy because they miss a lot of contextual information, then you end up with genuine problems to solve.
=> More informations about this toot | More toots from tealeg@mastodon.online
@jbqueru Bjarne Stroustrup noted that legacy code “often differs from its suggested alternative by actually working and scaling”. https://www.stroustrup.com/bs_faq.html#legacy
=> More informations about this toot | More toots from KarlPettersson@mastodon.nu
@jbqueru worst case, you understand it half way through replacing it, and now you realise you wouldn't have bothered if you started with that knowledge.
=> More informations about this toot | More toots from NaN@mastodon.green
@jbqueru @timbray Often, annoyingly, it seems to do Its Job and - this is the really annoying part - no one present understands what Its Job really is.
=> More informations about this toot | More toots from icing@chaos.social
@jbqueru @timbray Oh, it's a zen koan. Once you have understood the Legacy Code you will have understood that The Code never existed. Ah. The Tao.
=> More informations about this toot | More toots from jwz@mastodon.social
@jbqueru an essay I like on the topic is this classic https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
=> More informations about this toot | More toots from oblomov@sociale.network
@oblomov Very much so. I remember that article... right when I was in the middle of throwing a piece of code away and rewriting it (and, yes, looking back, that was a mistake).
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru Read it, understand it, model it, implement it.
Hope your modeling method can withstand the test of time.
https://fediscience.org/@JordiCabot/113819618021144896
=> More informations about this toot | More toots from morgendoen@mastodon.social
@jbqueru except dependent types....
=> More informations about this toot | More toots from apostolis@social.coop
@jbqueru I often do a thing where I mentally replace the word "legacy" with "successful" in these instances.
Because even if the code is old and gross, the bottom line is that it's apparently been around long enough to do whatever it was asked to do.
=> More informations about this toot | More toots from gregw@mastodon.world
@gregw I love that. Dead code isn't a big issue. Live code is. And that code is still alive because it works, because it's useful, because it's valuable.
=> More informations about this toot | More toots from jbqueru@fosstodon.org
@jbqueru @gregw In this context, legacy implies inherited value. If it didn't have value, it would be waste and we'd just throw it away.
=> More informations about this toot | More toots from arclight@oldbytes.space
@jbqueru The price of options is not the only considered criteria.
=> More informations about this toot | More toots from Anibyl@social.coop
@jbqueru
When I have faced this kind of task, I work to understand what it was intended to do not how it did it, treating the code as a spec for what is suppose to happen. Then isolate it and replace it with my new standard:-) was of doing it.
=> More informations about this toot | More toots from mral@mastodon.sdf.org
@jbqueru Related: https://legacycode.rocks/
=> More informations about this toot | More toots from skylark13@mastodon.gamedev.place
@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
@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 This content has been proxied by September (ba2dc).Proxy Information
text/gemini