filipefreire
@"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.
Ludovic :Firefox: :FreeBSD:
Irenes (many)@jbqueru well said
Nicole ParsonsOn 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.
Wulfy—Speaker to the machines
Jayne@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.
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.
Fish Id Wardrobe ⁂@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…
@fishidwardrobe @dotjayne @jbqueru
Counterpoint:
I think it was Knuth who said "If houses were built the way programmers code, the first woodpecker would collapse the civilisation"
A case in point to reinforce the non-destructive approach the Chestertons Gate...
...maybe just rename to OLD_ChestertonsGate.Production 😁
@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.
@jbqueru @fishidwardrobe @dotjayne
...and you get to look like a hero for "restoring" the service.
😁
@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…"
@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.
@jbqueru @fishidwardrobe @dotjayne
"Scream Tests, a more exciting alternative to boring documentation"
~ Wulfy
Thomas Sturm@jbqueru So true.
dandelionmood@jbqueru well put, and that definitely rings true with past experiences
Rachel Greenham@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
@jbqueru @ireneista of course the person who perpetrated the original went on to make a custom build “system" for the next big java project in a clusterfuck of python scripts instead.
replaced that with gradle too, then retired early, a crumbling cinder of my former self.
The Doctor
AN/CRM-114@jbqueru I have heard it said that legacy code is code without tests. There are people pumping out legacy code right now
The Long Tail@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!"
@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.
@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.
But code without tests is probably on the way to becoming legacy code, yes.
samir, an unknown quantity@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.
Very Human Robot
Dragon-sided D@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
Matt Palmer@dragonsidedd asking a machine designed to produce plausible sounding bullshit to produce understanding is unlikely to produce understanding, merely plausible sounding bullshit.
@womble I don't think you've designed many neural networks in your life.
From Papert to Hinton to Krizhevsky to Lecun, not one of their (breathtaking and brilliant) papers have to do with "bullshit".
Ludwig Vielfrass@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!
@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.
Avi Rappoport (avirr)@jbqueru But when it breaks, and it will break, ya gotta be able to fix the functionality.
Andreas 🌈@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.
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...
The ol' tealeg 🐡@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.
Karl Pettersson@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
Hayley/Dragon🏳️⚧️
Stefan Eissing
jwz
Oblomov@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/
@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).
חנן כהן • Hanan Cohen@jbqueru This is why COBOL programmers don’t die. They are not allowed to.
Morgen Doen@jbqueru Read it, understand it, model it, implement it.
Hope your modeling method can withstand the test of time.
Jordi Cabot (@[email protected])
Attached: 1 image Did you know that there is plenty of UML in the low-code world? (even if it's never acknowledged, I guess due to the bad press UML has and to better justify the "innovation" of the low-code tool by selling it comes with its own languages) 👇👇 https://modeling-languages.com/there-is-a-lot-of-uml-in-low-code/ #uml #dsl #lowcode #language #codegeneration #modeldriven
Apostolis@jbqueru except dependent types....
Greg Woods@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.
@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.
Sieva 🚴🚇🏙️🌹@jbqueru The price of options is not the only considered criteria.
AL@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.
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.
Arne Claassen@jbqueru Unfortunately often that new team plows into replacing before they understand it. Then they either release it half-baked, spending the next months patching it to bring it back to feature parity or realize they are missing the a lot, but continue on bolstered by the sunk cost fallacy.
Jean-Sébastien Guay@jbqueru Related: https://legacycode.rocks/
@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.
@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.