3 ms·

So for those who don't know, Microfocus is a retirement home for technologies that need to be taken out behind the barn and shot but can't be because there are

So for those who don't know, Microfocus is a retirement home for technologies that need to be taken out behind the barn and shot but can't be because there are like 3 major customers out there that have a Microfocus product as a core part of their organizational structure and can't move away from it. That being said my understanding has always been that learning COBOL was never the hard part, the hard part was always that it's not just COBOL it's learning the mainframe it runs on, and learning the JCL that is associated, and a dozen other pieces of finicky technology. Someone feel free to correct me if I'm wrong.

mr_00ff00 3y ago
In addition, I think the common saying “COBOL pays well, they are running out of COBOL devs!” is misrepresenting the issue. I heard this on HN, so this hearsay itself, but I believe it’s not that these companies can’t find people that can learn COBOL, it’s that there are people with 30+ years of COBOL experience on their codebase. The COBOL job security comes from being the only person who knows the codebase, not that somehow people can’t learn COBOL.
- devwastaken 3y ago
  We have an oversaturation of devs. There are no issues in hiring. If there ever becomes real issues then tech corps will actually spend money on education.
  - johnnyanmac 3y ago
    >If there ever becomes real issues then tech corps will actually spend money on education. are the systems so mission critical and complex that it's cheaper to spend money training devs on the system than it is to have the existing ones start to migrate the codebase to anything else?
    - WorldMaker 3y ago
      You may have to define "cheaper" for some of these companies. Keep in mind the sunk cost fallacy and that every million dollars invested in 1960s money is about ten million dollars in today's money. Some of these projects are so foundationally sunk cost to these companies that they might as well be load bearing sunk costs. The company doesn't think that it exists without those sunk costs, and the company doesn't think it could survive a second, similar spending program today, at least not without their shareholders pitching a fit in potentially lots of short-term quarters given current shareholder obsessively short-term thinking.
    - mr_00ff00 3y ago
      I think you are thinking about it all wrong. COBOL code that has been working since the 60s is a lot more safe than new code would be. If it is commission critical and complex, keep it in COBOL where it works and pay lots of cash for additional features. Rather then migrate it over in hopes you don’t have to pay for training, but then deal with tons of risk of systems breaking that haven’t broken in 50+ years.
      - tabtab 3y ago
        Whatever it's replaced with will be subject to the turbulence of whims and fads. COBOL is like ancient Latin: it ain't going nor coming.
- ecshafer 3y ago
  I worked at a finance company that still has a lot of cobol devs (cobol, jcl, db2) and they usually made less than the web / cloud devs given same seniority. There were plenty of contractors ready to step in and fill slots. I think this meme has a lot of caveats. There are some banks running very very specific old versions of mainframes and databases and thus need expertise, so they are paying high emergency consultant fees for the few with that expertise. The average developer is better off learning aws and python.
ecshafer 3y ago
I learned a little bit of COBOL when I worked in a finance company, just to help on call stuff. And I think you’re right. Learning COBOL the language is easy. It’s just an imperative language with no fancy constructs. But jcl and the specifics of db2 and mainframes, and also the weird terminal emulator you need to use to work with them is the hard part. Java is 100x more complicated than cobol, but mainframes and the surrounding infrastructure are very alien compared to todays stuff.
stcroixx 3y ago
True, but I’d not describe all those associated bits as finicky - they’re stable and very well documented, particularly compared to modern cloud tech.
karmakaze 3y ago
I can't speak for many of their products, but I thought the compiler tooling (back in the 90s) was great. Either cross-develop from PC (OS/2, Win NT) targeting mainframe emulation, or compile natively running even Win32 GUI apps with recursive calls. Ignoring that COBOL syntax is verbose, it seemed almost like a normal runtime.

mr_00ff00 3y ago

In addition, I think the common saying “COBOL pays well, they are running out of COBOL devs!” is misrepresenting the issue. I heard this on HN, so this hearsay itself, but I believe it’s not that these companies can’t find people that can learn COBOL, it’s that there are people with 30+ years of COBOL experience on their codebase. The COBOL job security comes from being the only person who knows the codebase, not that somehow people can’t learn COBOL.

devwastaken 3y ago
We have an oversaturation of devs. There are no issues in hiring. If there ever becomes real issues then tech corps will actually spend money on education.
- johnnyanmac 3y ago
  >If there ever becomes real issues then tech corps will actually spend money on education. are the systems so mission critical and complex that it's cheaper to spend money training devs on the system than it is to have the existing ones start to migrate the codebase to anything else?
  - WorldMaker 3y ago
    You may have to define "cheaper" for some of these companies. Keep in mind the sunk cost fallacy and that every million dollars invested in 1960s money is about ten million dollars in today's money. Some of these projects are so foundationally sunk cost to these companies that they might as well be load bearing sunk costs. The company doesn't think that it exists without those sunk costs, and the company doesn't think it could survive a second, similar spending program today, at least not without their shareholders pitching a fit in potentially lots of short-term quarters given current shareholder obsessively short-term thinking.
  - mr_00ff00 3y ago
    I think you are thinking about it all wrong. COBOL code that has been working since the 60s is a lot more safe than new code would be. If it is commission critical and complex, keep it in COBOL where it works and pay lots of cash for additional features. Rather then migrate it over in hopes you don’t have to pay for training, but then deal with tons of risk of systems breaking that haven’t broken in 50+ years.
    - tabtab 3y ago
      Whatever it's replaced with will be subject to the turbulence of whims and fads. COBOL is like ancient Latin: it ain't going nor coming.
ecshafer 3y ago
I worked at a finance company that still has a lot of cobol devs (cobol, jcl, db2) and they usually made less than the web / cloud devs given same seniority. There were plenty of contractors ready to step in and fill slots. I think this meme has a lot of caveats. There are some banks running very very specific old versions of mainframes and databases and thus need expertise, so they are paying high emergency consultant fees for the few with that expertise. The average developer is better off learning aws and python.

ecshafer 3y ago

I learned a little bit of COBOL when I worked in a finance company, just to help on call stuff. And I think you’re right. Learning COBOL the language is easy. It’s just an imperative language with no fancy constructs. But jcl and the specifics of db2 and mainframes, and also the weird terminal emulator you need to use to work with them is the hard part. Java is 100x more complicated than cobol, but mainframes and the surrounding infrastructure are very alien compared to todays stuff.

stcroixx 3y ago

True, but I’d not describe all those associated bits as finicky - they’re stable and very well documented, particularly compared to modern cloud tech.

karmakaze 3y ago

I can't speak for many of their products, but I thought the compiler tooling (back in the 90s) was great. Either cross-develop from PC (OS/2, Win NT) targeting mainframe emulation, or compile natively running even Win32 GUI apps with recursive calls. Ignoring that COBOL syntax is verbose, it seemed almost like a normal runtime.