3 ms·

Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the

Yes... We have some high revenue, important contract type systems written a long time ago and maintained by the same subject matter experts who simply move the codebases (old and new) to newer systems and stacks. As you can tell, the SMEs have no interest in learning other things and so any new initiatives that require them to implement it is subject to their preferences.

hinkley 6y ago
Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers. You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way. So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.
- gmmeyer 6y ago
  There's no need to rewrite a system that works and that you're not gonna change. While programming languages go out of fashion there will always be people who are capable of writing them. The median age of a cobol programmer has not changed in 20 years because more people keep learning the language. Demand in this case, will likely create its own supply.
  - hinkley 6y ago
    I tend to replace my car when it starts to show signs of future problems, not when I'm up to my eyeballs in repairs. We shouldn't really be treating software differently. The liability for a mission critical system that works but cannot be repaired climbs over time. Just because it works doesn't mean it isn't broken.
    - derriz 6y ago
      That analogy doesn't really work - software doesn't get worn out from interaction with users. If software is working and in use, then it's age doesn't matter. Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.
      - hinkley 6y ago
        Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be. And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
  - ChiranSoogoor 6y ago
    Wisdom is in not in spending years and millions rewriting billions of lines of cobol code into a new language and then rewriting that other language into another newer language and so on … what's the problem in maintaining what's already working?!!
- CountSessine 6y ago
  the will create a new team to rewrite it badly because now they have no other choice Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
- yellowapple 6y ago
  > and it’s hard to impossible to find Perl programmers Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon. That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point. My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned). Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.
  - hinkley 6y ago
    A former boss was fond of saying "Software is done when nobody is willing to work on it anymore." New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is. I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.
- codr7 6y ago
  There are plenty of silly reasons to rewrite a piece of code, but language preference has to be one of the worst. Now that I think about it, that's actually a decent hiring test: Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them. It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.

hinkley 6y ago

Many places don’t support antifragility. Having an old system that nobody wants to rewrite may not be a reflection on the engineers. You’re an expert, and a rewrite is going to expose you to a lot of scrutiny. You are going to break things, when maybe you haven’t broken things in a long time and people like it that way. So when some day arrives where a new fad is hot and it’s hard to impossible to find Perl programmers, the will create a new team to rewrite it badly because now they have no other choice. And of course the new folks are going to screw up, but that’s just expected.

gmmeyer 6y ago
There's no need to rewrite a system that works and that you're not gonna change. While programming languages go out of fashion there will always be people who are capable of writing them. The median age of a cobol programmer has not changed in 20 years because more people keep learning the language. Demand in this case, will likely create its own supply.
- hinkley 6y ago
  I tend to replace my car when it starts to show signs of future problems, not when I'm up to my eyeballs in repairs. We shouldn't really be treating software differently. The liability for a mission critical system that works but cannot be repaired climbs over time. Just because it works doesn't mean it isn't broken.
  - derriz 6y ago
    That analogy doesn't really work - software doesn't get worn out from interaction with users. If software is working and in use, then it's age doesn't matter. Evolution/flux is not the natural state of all software. I've seen plenty of business/enterprise software which has continued to provide business value for decades without structural or architectural changes.
    - hinkley 6y ago
      Lots of security patches and infrastructure are held hostage by breaking changes to APIs. Eventually you have to upgrade, and the longer you have put it off the more painful it will be. And as we've seen with old video games, there are lots of timing problems that you simply never encounter on the original hardware but are impossible to ignore on recent vintage hardware.
- ChiranSoogoor 6y ago
  Wisdom is in not in spending years and millions rewriting billions of lines of cobol code into a new language and then rewriting that other language into another newer language and so on … what's the problem in maintaining what's already working?!!
CountSessine 6y ago
the will create a new team to rewrite it badly because now they have no other choice Given Perl’s legendary code-opacity and maintenance challenges, this kind of seems inevitable. After all, if you could at least read and decipher the old code, maybe you could reproduce it!
yellowapple 6y ago
> and it’s hard to impossible to find Perl programmers Which I'm finding harder to understand as I learn more languages. Yeah, every language has its differences and idiosyncrasies, but as long as you have access to docs (if not third-party resources like expert blogs or Stack Overflow) it's pretty straightforward to figure those out and be reasonably productive relatively soon. That is: a senior programmer should have enough background knowledge to be able to be productive on any language ("polyglot" shouldn't be a big deal), and a junior programmer won't typically have enough experience in any particular language to be definitively a "$LANGUAGE programmer". In either case, whether or not a programmer already knows the language before being hired is kind of a moot point. My current dayjob was the first time I had written any non-trivial amounts of Python, Javascript, or C# in a professional capacity in my whole career. Being productive on them wasn't terribly hard - it's just different syntax around a lot of the same concepts (and sure, there were also some new concepts - took a good while for me to wrap my head around async/await, for example, coming from a background of message passing between threads or processes or actors - but those can be learned). Usually the choice of programming language is far less significant as a barrier to one's understanding of a codebase than, say, the actual problem domain. Writing software for, say, a warehouse tends to necessitate knowing an awful lot about how warehouses work; whether or not you happen to know a given programming language is entirely secondary to whether or not you know the difference between a picker and a packer, or between a replenishment and a cycle count. Similar deal in medicine, or education, or manufacturing, or sales, or finance, or what have you.
- hinkley 6y ago
  A former boss was fond of saying "Software is done when nobody is willing to work on it anymore." New people make idiomatic mistakes, and if the language isn't cool they expect more money. Recruiting people is harder, so you tend to get stuck with the people you have, and managers tend to bristle at that. Eventually a new language full of people who look like cogs is going to win out. I hate that this is true, but it is. I maintained a Python test harness for a while. No prior experience with Python. I mostly stayed out of trouble, in part because I set low expectations, tried nothing fancy. But it wasn't what I wanted to be doing, and not what I wanted the team to be doing. When I left they finally canned the entire thing.
codr7 6y ago
There are plenty of silly reasons to rewrite a piece of code, but language preference has to be one of the worst. Now that I think about it, that's actually a decent hiring test: Tell the candidate part of their job will be maintaining a small Perl codebase. If they can't deal with that without throwing a fit, I have no interest in working with them. It's a sharp tool, if you're not careful someone might get hurt. But professionals deal with sharp tools all the time, especially when it's the best tool for the job.