Should I bother that my employer don't consider moving away from an ancient compiler a priority?
-
It reached its end of life in 2008, lot's of newer code and libraries are incompatible with this.
Some black magic was required to run the application inside kubernetes and there is no guarantee it won't crash on newer versions of the host OS
But as long as people manage to keep it running, management doesn't give a shit
-
I guarantee as soon as the black magic stops working, it will be an immediate flaming priority to fix.
Management never learns about paying off technical debt.
-
@Arantor said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
I guarantee as soon as the black magic stops working, it will be an immediate flaming priority to fix.
Management never learns about paying off technical debt.
I’ve seen two priority level: 0 and critical. The higher only happens when the system is melting down, and generally costs the business more than it would have to do it earlier.
-
"This migration is going to happen. There's no way around it, it's a law of nature. All that's left to decide is this: Do you want it to be planned, handled easily, carefully, and without negative impact, like all of our other work? Or do you want it to be unplanned, destroying a quarter and becoming an embarassment to our customers?"
-
@TwelveBaud said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
"Do you want it to be planned, handled easily, carefully, and without negative impact, like all of our other work? Or do you want it to be unplanned, destroying a quarter and becoming an embarassment to our customers?"
"Which one will get me the bigger performance bonuses?"
-
@Watson The first one, obviously. The second one might get you hailed as a hero and put another notch on your belt for golden paragliding, but any performance-based incentives will get completely zeroed.
-
During my job search, I found more than one company which has to move away from Oracle Forms because Oracle eventually decided to announce its end...
-
@BernieTheBernie I remember that. The mortgage system I used to look after before the financial services world imploded was based on that.
It wasn't great.
-
@TwelveBaud said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
planned, handled easily, carefully, and without negative impact, like all of our other work?
that's not how we do our other work
-
@sockpuppet7 said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
It depends a lot on contexts. There may be valid reasons for it, somewhat valid reasons or completely dumb reasons.
Valid reasons might be if the code still needs to run on some platform that is not getting updated either. For example in 2016 I was still using Visual Studio 2008, because it was the last one that came with an SDK for Windows CE and I needed that because it was still used on some single-use portable devices.
In general, when custom hardware is involved, this is rather common. It is a lot of work to set up the toolchain and that kind of software usually doesn't use many external dependencies anyway, so people tend to stick with the ancient but working compiler and that's fine.
Another valid reason that comes to mind is maintenance of qualified software. If you have something safety critical, you are required to have certain test coverage, and upgrading the compiler means redoing a lot of them to gain confidence it's not miscompiling your code, so if you are just doing small updates to existing software, it makes sense to stick with the already tested and validated compiler. Major version that will require full testing anyway should still be taken as opportunity to also upgrade the toolchain though.
It reached its end of life in 2008, lot's of newer code and libraries are incompatible with this.
That, however, starts to sound like it's none of the above. Old versions of libraries had more time to have security vulnerabilities discovered in them, so you don't want to stick with them unless it's not network connected …
Some black magic was required to run the application inside kubernetes and there is no guarantee it won't crash on newer versions of the host OS
… which clearly isn't the case. It shouldn't take any black magic to run old application inside kuberentes. Kubernetes runs shit in containers, which can simply contain old versions of the userland. And Linux kernel keeps excellent backward compatibility (libc does not, but that's what the container is for), and Windows kernel does as well if it's using that.
But as long as people manage to keep it running, management doesn't give a shit
Management shouldn't give a shit, and shouldn't need to give a shit. It's up to the technical people to decide whether it makes more sense to patch up the old version or get it working with a new one, and just include the upgrade in the next larger feature from the management point of view.
It's running in Kubernetes, it shouldn't concern operations or customer which toolchain it was built with. Or does it for some weird reason?
-
@Bulb said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
It's up to the technical people to decide whether it makes more sense to patch up the old version or get it working with a new one
They'll still need to explain to management why this simple change requires so much more time than all the other simple changes they'd done in the past.
Problem with these technical debt issues is that you can always do them "just a little bit later", until shit actually hits the fan.
-
@ixvedeusi said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
Problem with these technical debt issues is that you can always do them "just a little bit later", until shit actually hits the fan.
And, to be fair to management (
), technical experts sometimes cry wolf ("it is critical that we update to version 2023.142.12 now otherwise there is a tiny risk that hackers willing to spend 2 weeks of CPU will get the IP of our last 3 visitors!").
-
@ixvedeusi said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
@Bulb said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
It's up to the technical people to decide whether it makes more sense to patch up the old version or get it working with a new one
They'll still need to explain to management why this simple change requires so much more time than all the other simple changes they'd done in the past.
Some balance needs to be found by the senior developers. You don't just attach refactoring to what actually is a simple change. For those, don't fix what ain't broken applies. You attach it to a feature when the annoyance of the technical debt tangling your feet is noticeable, at which point the estimate is large enough to cover some repaying of technical debt.
It does have one prerequisite to work. The technical leader has to have enough assertiveness and enough respect to maintain that if the estimate is three weeks, then it won't be sooner than in three weeks even if the managers stand on their heads. Teams that cave in to business side pressure will end up with a lot of technical debt and there ain't much that can be done about it until they learn to claim their breathing space.
Problem with these technical debt issues is that you can always do them "just a little bit later", until shit actually hits the fan.
It requires some skill and experience on the part of technical leader and product owner to balance when to hack things together because this time business is right that it will make big impact to the bottom line and when to do things properly because the camping ground is getting messy. And understanding from all of the team, because if junior developers start telling business that they can just quickly hack this or that, the insistence on timelines will fall apart.
-
@remi said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
@ixvedeusi said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
Problem with these technical debt issues is that you can always do them "just a little bit later", until shit actually hits the fan.
And, to be fair to management (
), technical experts sometimes cry wolf ("it is critical that we update to version 2023.142.12 now otherwise there is a tiny risk that hackers willing to spend 2 weeks of CPU will get the IP of our last 3 visitors!").That's why it's useful to have a product owner who understands some of the technology and some of the business and can do proper prioritization. Good ones are, unfortunately, extremely hard to come by.
-
@Bulb said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
In general, when custom hardware is involved, this is rather common. It is a lot of work to set up the toolchain and that kind of software usually doesn't use many external dependencies anyway, so people tend to stick with the ancient but working compiler and that's fine.
We did that in my last project, maintaining our code using a very old version of gcc and armcc. With weird compiler bugs, naturally. Eventually we upgraded the gcc version (because we couldn't configure supported versions of container hosts to use that old version any more) and found that it was now producing better code than armcc with no bizarre internal bugs. Dropping armcc was nice; no more screwing around with VPNs to extend the FlexLM license into the cloud... which was good because all that stuff would have broken a few months later for other, unrelated reasons.
-
@Bulb I should have expected someone would imagine scenarios were that would be justified, but I assure you the only reasoning used is the time and cost of doing the moving
@Bulb said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
… which clearly isn't the case. It shouldn't take any black magic to run old application inside kuberentes. Kubernetes runs shit in containers, which can simply contain old versions of the userland. And Linux kernel keeps excellent backward compatibility (libc does not, but that's what the container is for), and Windows kernel does as well if it's using that.
We're talking about an old, windows 32 bit only compiler, full of incompatible extensions and libraries, running on windows containers over kubernetes
@Bulb said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
Management shouldn't give a shit, and shouldn't need to give a shit. It's up to the technical people to decide whether it makes more sense to patch up the old version or get it working with a new one, and just include the upgrade in the next larger feature from the management point of view.
The top lead say that the longer term plan is to split the program into smaller components and rewrite them, which is happening slowly, and I have to concede is a reasonable plan.
It's just too slow, and I still feel like I want to scream every time I need to do something on arcane stupid compiler
-
@sockpuppet7 said in Should I bother that my employer don't consider moving away from an ancient compiler a priority?:
We're talking about an old, windows 32 bit only compiler, full of incompatible extensions and libraries, running on windows containers over kubernetes
If there is a lot of non-standard extensions (and they are used in the code a lot), it sounds like a trap that does not have any easy way out.
The top lead say that the longer term plan is to split the program into smaller components and rewrite them, which is happening slowly, and I have to concede is a reasonable plan.
That does, indeed, sound like a reasonable plan. When you've got a Big Ball of Mud on your hands, you have to start by splitting it up to components and then clean them up one by one. Because you can't be refactoring everything at once, and moving from one working state to another reasonably close working state is the only way to avoid making just as many errors as your predecessors did when initially writing that thing.
It's just too slow, and I still feel like I want to scream every time I need to do something on arcane stupid compiler
Everything always feels too slow in our line of work. You know Hofstadter's law, don't you?
Do you have linking between objects built by the antediluvian compiler and objects built by something more recent and standard working? You'll probably need it for the gradual rewrite anyway. If yes, you can try cleaning up at least some parts to switch them over sooner. If not, well, you are in a fix and it is going to be slow.
-
Btw, you have Lounge access, haven't you?
So you nay read that short anecdote which I posted there, and, well, was not wrong....
@BernieTheBernie said in How Soon Is Now:
