6 ms·

It sounds like you haven't been in the situation the parent is describing. I have and still am. We have stuck one ancient piece of software in a docker contain

It sounds like you haven't been in the situation the parent is describing. 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

ramesh31 4y ago
>It sounds like you haven't been in the situation the parent is describing. 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.
Micoloth 4y ago
That's amazing! Can you share more about what sector you are working in and what the software in question does?
WesolyKubeczek 4y ago
The problem that your product owner cannot see any value in replacing/understanding/modernizing that piece of software, but should it fail, the heads would roll, speaks of a bigger problem in your organization than an ancient piece of software. 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.
intrasight 4y ago
What would be an example of such a software company? 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.
- guntherhermann 4y ago
  In my haste to give an example I missed the part about it being for only "software companies", we're not a software company, but we do have a lot of developers
civilian 4y ago
This is absolutely a failure of management. Both the general management and _especially_ the engineering management. 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.
btilly 4y ago
Nobody in the department understands Perl or wants to. 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!
- jasonlotito 4y ago
  > And that is the problem. 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.
  - btilly 4y ago
    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.
lumb63 4y ago
> This software is OLD, early Perl 5 old Heh, it never fails to crack me up how relative old is. I’ve worked on software that predates Perl, and even UNIX itself…

ramesh31 4y ago

>It sounds like you haven't been in the situation the parent is describing. 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.

Micoloth 4y ago

That's amazing! Can you share more about what sector you are working in and what the software in question does?

WesolyKubeczek 4y ago

The problem that your product owner cannot see any value in replacing/understanding/modernizing that piece of software, but should it fail, the heads would roll, speaks of a bigger problem in your organization than an ancient piece of software. 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.

intrasight 4y ago

What would be an example of such a software company? 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.

guntherhermann 4y ago
In my haste to give an example I missed the part about it being for only "software companies", we're not a software company, but we do have a lot of developers

civilian 4y ago

This is absolutely a failure of management. Both the general management and _especially_ the engineering management. 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.

btilly 4y ago

Nobody in the department understands Perl or wants to. 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!

jasonlotito 4y ago
> And that is the problem. 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.
- btilly 4y ago
  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.

lumb63 4y ago

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