I have and still am. We have stuck one ancient piece of software in a docker container and have our fingers crossed that it continues to work. This software is OLD, early Perl 5 old. Nobody in the department understands Perl or wants to. The business (read: product owner) has deemed it unimportant to update or understand, but I assure you that if it stopped working, it would affect millions of tax payers, upper management would find out (read: VP, CEO), and heads would roll.

Everything is fine, until it isn't.

Your thinking from the perspective of a startup might be true, but from the perspective of a company that is many decades old and has a dozen layers of management... perhaps not so much

Eng management needs to convey that this is an Achilles' heel that is important to understand & be able to update.

No engs want to work on perl5? Bribe existing employees, hire someone who wants to work on perl5, or a darker third option.

The product owner can even spin this as them doing a good thing to future-proof the business, even if it means their team loses velocity on other projects.

And that is the problem.

I don't know how bad that code is - a lot of Perl code from that period is not good - but learning enough Perl to have a shot at it literally should take a competent developer a few minutes if you had someone explain it to you.

You might find the language weird. $ means "the". @ means "these". % indicates you're building a lookup. Which you then access with braces. So %foo is a lookup. And $foo{$bar} should be read "the foo of the bar...".

Early Perl 5 means it probably doesn't use references or objects. You do use regular expressions. While regular expressions are built into Perl in a way that makes them easy to use, Perl-like regular expressions are in pretty much every language. So the effort you need to use them is directly portable to Python, JavaScript, Java, etc, etc, etc.

Fluency takes a lot longer. But getting to the point of "I can puzzle my way through a language I don't know well" should be doable very quickly. And it is a skill that every developer should build. Because I guarantee that whatever language and toolset you are using now, you'll need to be able to switch at some point in your career. And practicing in advance will help you. Plus being the person who can puzzle out old ganky code in another language lets you be a hero in fun ways!

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.

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.

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.

Yeah, but the motivation to learn Perl 5 as your next language is about as wise as learning COBOL as your next language.

That's probably why parent is finding it hard to get his developers to work on it - lots of effort for negative gain[1]. Anyone wanting to learn Perl 5 in 2023, for no additional money, is probably legitimately crazy.

I don't understand why you don't see the problem that parent has - no one wants to learn Perl 5 because it is a dead-end, and takes up energy that would otherwise be spent moving your career forward.

[1] The opportunity cost is immense - the time used to learn Perl 5 enough to maintain the legacy code is time that could have been used to learn a current language that results in a payoff.

Sure I have. And the first few times I too thought that it mattered. But it doesn't. None of the stuff we care about as software developers actually matters. We are just pawns for the people making money decisions. Completely replaceable automatons. If what you are doing is not directly supporting a strategic business goal, you are doing nothing but costing a business money. And cost centers are the first to be cut. You can sit there with your sense of self importance, thinking that the cleanliness and elegance of your code matters. But it just doesn't. Nobody cares. And the sooner you let go of thinking it matters the sooner you can focus your effort on what does.

The reality is that when whatever old house of cards you're running fails for whatever reason, the business will switch to a vendor that covers 95% of the use case, while being much cheaper and not requiring FTE support. It will be a tiny bump in the road for the business, replacing this thing that you thought was a world beating make or break technology.

I am always faced with this issue with non-software companies in industries where I've worked such as nuclear, defense, energy, and healthcare. At these places, I've confronted "hands-off" modules that are effectively black boxes of complex logic that has been vetted over decades, is written in C or Fortran, and nobody is allowed to modify.

I can't imagine that situation existing in a software company.

You have been able to put it in a container and it’s running, so unless the kernel itself changes drastically so old libc will just stop working, it’s going to be able to work unchanged for a decade more.

But the communications problem between management layers is way bigger than that, and could probably bite in some other situation.

Heh, it never fails to crack me up how relative old is. I’ve worked on software that predates Perl, and even UNIX itself…

This includes things like airline reservation systems, scientific computing models, compilers for obscure dsls, and the like.

Companies doing rewrites every three years have a hard ceiling.

That's a blind jump. We don't know the purpose, we don't know how much was invested, how much was already recovered, and how much more could be earned if the program was allowed to live.

All we know is that it has recently hit fitness to purpose, and that the fitness caused it to be abandoned.