> the business (read: product owner) has deemed it unimportant to update or understand,
That's the problem. It's not on a random person in the department to spend their own time trying to solve a problem the business doesn't want invest time or money into solving. I don't see you offering to do this for free, so don't claim that's a problem for others.
I've been around the block enough to read between the lines on this one.
All of the talk about how old and bad the language is, and how nobody wants to learn it is tech speak for, "We can't support it as is, we need a rewrite!" Anyone who has been near tech for a long time knows "rewrite" means "tech is going to break it for unclear reasons and uncertain gain, and in a few years will want to rewrite it again. Tech people always underestimate the cost and risk of a rewrite, and also overestimate the benefits.
Business is not being stupid in saying that tech can't rewrite the software. The software is there, works, and is being relied on. Tech should figure out how to support it without a risky rewrite. Don't stand on, "We don't want to learn Perl." Learn how to be a polyglot. At least when it comes to reading. And to the extent that tech understands the value of being prepared, tech should prepare in advance. And figuring out how to read the code is most of that battle.
Now you accuse me of not offering to do this for free. But in fact I offered the best tip I could for a non-Perl programmer who is trying to puzzle their way through an early Perl 5 script. Given that I'm an internationally recognized expert in Perl, that tip probably does more good than you realize. Learning how to navigate legacy code in a legacy language is a learnable skill. And you learn it by trying, then finding you can. And no matter how much you don't wish to learn any particular legacy language, having the confidence to know you can is valuable.
> All of the talk about how old and bad the language is, and how nobody wants to learn it is tech speak for, "We can't support it as is, we need a rewrite!" Anyone who has been near tech for a long time knows "rewrite" means "tech is going to break it for unclear reasons and uncertain gain, and in a few years will want to rewrite it again. Tech people always underestimate the cost and risk of a rewrite, and also overestimate the benefits.
No, it really isn't. I'm happy to learn a new language. The reason is correctly stated by a sibling post here (WesolyKubeczek).
That we've been able to containerise it has limited a lot of the risk, and any upstream issues we have going forward we should be able to write some middleware to sit between it and transform the data into the format we need. We can extend the container to proxy any requests from the ancient application to the new middleware. We have a strategy, the product owner is happy with that, but we've outlined that maybe the solution won't work as we think, there are always unknown unknowns...
The issue is that if a problem does arise, it will be immediate and the effects will be there for as long as it takes to get a fix up and running, which could be weeks to who knows how long. That's a real risk in my eyes, but it wasn't to our product owner.
It will affect a lot of people, it's a pretty widely used service! It's entertainment, so people won't die if it fails.
The risk was deemed low enough by the product owner that we can just leave it in a container until it's finally sunsetted in 5-10 years (or so...). We've had 2 product owners since the OG product owner made that decision, so it could just be the product owner who made the decision thought they'd be long gone by the time it became an issue.
You're making assumptions about people you've never met, you don't know me and you don't know what motivates me.
You aren't as good at "reading between the lines" as you think you are.
---
From your profile: My main programming language is Perl
Oh, it all makes sense, you're hurt that I called Perl 5 old! That's funny. I've never written production Perl, I am not making a judgement on the language.
No, that's not the problem.
> the business (read: product owner) has deemed it unimportant to update or understand,
That's the problem. It's not on a random person in the department to spend their own time trying to solve a problem the business doesn't want invest time or money into solving. I don't see you offering to do this for free, so don't claim that's a problem for others.