15 ms·

The idea that large corporations are simply going to move on from COBOL is out of touch with reality. It really can't be overstated how deeply old COBOL program

The idea that large corporations are simply going to move on from COBOL is out of touch with reality. It really can't be overstated how deeply old COBOL programs are embedded into these corporations. I worked for one that had been using them since the language itself was created, and while they all could see the writing on the wall, the money to do the change simply wasn't there. Not only would they have to do a code change, they would also have to do a hardware change because all of this is running on mainframes. Not only does this cost a lot of money, but it would also take an enormous amount of time. What mid-level manager is going to stick their neck out and push for this? What exec is going to ignore the guaranteed transactions that a mainframe and a decades-old COBOL program can offer simply to secure a solid future for which they may not even be around for? But as far as training people to handle COBOL, well, that's simple. Look at vocational schools of years past. Why can't you train a random person just how to do COBOL? They don't need to do object-oriented programming or UX theory. They just need to maintain and occasionally update some ancient program that's been rock-solid for longer than they've been alive. It doesn't take a genius, it just takes very specific training. And there are a lot of people that would jump at a chance for some high-paying, steady job that they just need to train for a year or so at night school.

nickpsecurity 9y ago
"But as far as training people to handle COBOL, well, that's simple. Look at vocational schools of years past. Why can't you train a random person just how to do COBOL? " You can. Our local, community college ties its classes to what industry in the area wants. It has classes on COBOL, RPG, and so on. That's because there's quite a bit of it out here in big companies.
- bluedino 9y ago
  Learning cobol (or any language) isn't the hard part - its understanding a massive legacy codebase and business practices that's the hard part.
  - nickpsecurity 9y ago
    Yep.
scrollaway 9y ago
Realistically, if, say, one of these big corps/banks with deeply-integrated COBOL systems spent a few years revamping their systems to something more modern and usable today, how much would it cost? Running mainframes isn't cheap. COBOL programmers aren't cheap. Not being able to improve these systems / innovate with them can cost the business a lot of time/money. And if we're talking COBOL, we're talking at least 25 year old corps. How long's the ROI on moving over? How expensive does the maintenance of antiquated systems get? It's easy to say that they're rock-solid and never need to be touched, but is that really true? For example, lot of banks today have a lot of absurd UX, often because of absurd internals and I know a lot of that usually is "the system is ancient and nobody really touches it anymore, that's just what it is now".
- protomyth 9y ago
  > Realistically, if, say, one of these big corps/banks with deeply-integrated COBOL systems spent a few years revamping their systems to something more modern and usable today, how much would it cost? What language would you suggest? Remember that decimal reliability and predictability is important. Plus, let's pick a language likely to have a very long service life because we need to have our investment rewarded. Frankly, the iSeries machine we have is pretty cheap to run. We bought it 10 years ago for about $15k and have had a maintenance contract that doesn't cost that much (about the same as our Red Hat service contract). We probably will buy another one since they just released a sub $10k one that will more than meet our needs. Never lost any data, easy enough backup that the biz office does it themselves[1], and IBM is pretty quick about any fixes. Much cheaper than any Linux, BSD, or Windows system we have ever had. Plus, I don't mess with it like the others. It just works. 1) we've tested it multiple times, after all, an unrestored backup is not a true backup
  - scrollaway 9y ago
    I don't know enough about these systems to suggest a language, but I imagine within the "a few years of development" is budgeted some time to figure out what tool to use. Surely you're not telling me that mainframes running COBOL is the best tool for the job. What languages do younger banks use?
badloginagain 9y ago
That also provides a vector for experienced COBOL devs to make _serious_ money as instructors. Banks would fly out trainees anywhere on the planet for any fee if it meant critical systems have the necessary ops guys. It's also a great proposition for a grad student. They don't have to unlearn much, they're in a perfect position to absorb a new language, and the term 'set for life' can be thrown around liberally. Wouldn't be surprised if this was already a thing, probably in the form of COBOL-specific Consultation services.
- braymundo 9y ago
  There is: http://cobolcowboys.com/ http://cobolcowboys.com/
f4rker 9y ago
"The idea that large corporations are simply going to move on from COBOL is out of touch with reality" Thank you. So much internet arm chair analysis falls into this category.
- lowken10 9y ago
  The company I work for has piles of Visual Basic 6 code that will be here for as long as their product is viable (Prepaid credit cards services). The growth is simply not their to perform a rewrite. It's sad but is also a reality.
  - Koshkin 9y ago
    I clearly remember VB6 being an excellent tool. Quality of code varied widely between developers.
    - shepardrtc 9y ago
      VB6 was incredibly easy to work with, and honestly, the value it provided by being able to link a quickly-made, solid UI with easy, solid code was highly underrated.
      - noir_lord 9y ago
        Same with Delphi which had a better underlying language than BASIC, fast compiles, superb version support and a stunning VCL (visual component library), it took VS studio years to catch up with a lot of that.
woliveirajr 9y ago
I don't understand why there wouldn't be at least 2 or 3 students, in any graduation class, interested in learning some language (and everything around it, since COBOL isn't just about the language but understanding business and computation in another paradigms). Do all students just care about learning the hype and creating the next flapping bird game?
- cafard 9y ago
  A sometime co-worker, probably in his late 20s, emailed me from the Data Science bootcamp he was attending to ask a question about COBOL. He is not interested himself, but somebody else in the class has heard that it pays well. I gave him what I thought was the email for our shop's last (now retired) COBOL guru, and recognized GNUCobol as a place to start.
- lovich 9y ago
  When I first started getting into development I took a look at it because I heard of the great money you could get if you were an expert in it. From what I could tell at the time, 5-6 years ago, it was both a lot harder work to even learn anything more modern just due to the lack of a community that had put all of their knowledge online and a risky proposition. The money looked good, but you severely limited the number of places you worked and if the industry ever decided to get off its ass and change over in even low double digit percentages you were likely to be out of work and with skills that didnt really transfer
- jetti 9y ago
  I was interested in COBOL while doing my MS in CS (coming from non-CS undergrad) but the problem was tooling and projects. I gave up after trying to track down z/OS, install hercules and get all that tooling set up. There is more to learning development on these old applications than just COBOL though, you need JCL and other applications/tools that go along with it. I ended up giving up because it just became too much of a hassle. Creating a new flapping bird game is exciting for students because it can give them an opportunity to create something from nothing. You aren't going to get that opportunity doing COBOL development. You will most likely spend the rest of your career doing maintenance work rather than any greenfield development. There is nothing wrong with that but not everybody likes the fact they can't create something new.
amorphid 9y ago
Object oriented COBOL is actually a thing now :)
- cafard 9y ago
  It has been for a while. Probably it was last year when we threw out a bunch of Microfocus Object COBOL documentation acquired about 1987. Let me add that I know essentially nothing about COBOL.
lithos 9y ago
They already do this. At my old tech school there was almost a rotation of COBOL/RPG instructors back and forth between the schools/businesses. Along with those businesses paying for some of their own to go through the classes. Other companies have worked together to essentially make boot camps before SV even thought to do so.
mamcx 9y ago
> the money to do the change simply wasn't there. This is a good excuse for a few years. But after decades? And talking about banks? --- The whole software industry is frankly pathetic. We are talking about actors with the HIGHEST profits of mankind, and yet "we don't have money for this" star to look pathetic. Google, Apple, MS, IBM, Oracle, Banks, Defense industry, etc have not excuse to not invest in basic infrastructure. This is the same thing with country that neglect self-investment in fundamentals. If you agree is smart to invest in road, electric grid, etc, then why we think otherwise when we talk about OUR industry.?
- wahern 9y ago
  Talk is cheap and rarely includes a full accounting of real-world constraints. You can tell what a person's _real_ priorities are by what they do. Likewise, you can tell what a society's real priorities are by what they do.
  - mamcx 9y ago
    >Talk is cheap and rarely includes a full accounting of real-world constraints. Of course. But after decades of the same problem, is not time to admit that is time to change?
    - wahern 9y ago
      Everybody always complains about the weather but nobody ever does anything about it. In other words, even though everybody complains about something, and even though it's theoretically fixable, the cost+benefit isn't always there. That doesn't stop people from complaining or offering conceptual solutions. If nobody pursues a particular solution, that's strong evidence about the real implementation and problem costs. Not conclusively, of course. But as a passive observer it's usually the best evidence available. Really, the answer to the COBOL "problem" is obvious and it's what basically anybody familiar with it suggests: a piecemeal and gradual shift according to cost, benefit, and opportunity.
- nikdaheratik 9y ago
manyxcxi 9y ago
A project I lead at least ten years ago was all about moving a company away from a COBOL based system- huge piles of money were an option and the timeline was in the 3-5 year range, and still everyone (myself included) thought there were better options all around. The driving factor was a suite of new services and features they wanted to implement, we came up with a creative way to run parts of the system as proxies to the COBOL applications backing them and to decorate the requests and responses with data from the newer systems. We were done much faster and cheaper, for a project of its scope there were surprisingly few hiccups or post launch rework projects, and we got the end result they could've spent 10x the money to achieve- and all with way lower risk. I'm assuming we were in a fortunate position that the general flow of data could be handled from the various source streams, but I wonder why this isn't at least an option for moving forward from some of these ancient systems. It seems like a good first step, at least.
arvinsim 9y ago
But something has got to give down the road, right? I feel sorry for the future guy who will be forced by circumstances to do the change.

nickpsecurity 9y ago

"But as far as training people to handle COBOL, well, that's simple. Look at vocational schools of years past. Why can't you train a random person just how to do COBOL? " You can. Our local, community college ties its classes to what industry in the area wants. It has classes on COBOL, RPG, and so on. That's because there's quite a bit of it out here in big companies.

bluedino 9y ago
Learning cobol (or any language) isn't the hard part - its understanding a massive legacy codebase and business practices that's the hard part.
- nickpsecurity 9y ago
  Yep.

scrollaway 9y ago

Realistically, if, say, one of these big corps/banks with deeply-integrated COBOL systems spent a few years revamping their systems to something more modern and usable today, how much would it cost? Running mainframes isn't cheap. COBOL programmers aren't cheap. Not being able to improve these systems / innovate with them can cost the business a lot of time/money. And if we're talking COBOL, we're talking at least 25 year old corps. How long's the ROI on moving over? How expensive does the maintenance of antiquated systems get? It's easy to say that they're rock-solid and never need to be touched, but is that really true? For example, lot of banks today have a lot of absurd UX, often because of absurd internals and I know a lot of that usually is "the system is ancient and nobody really touches it anymore, that's just what it is now".

protomyth 9y ago
> Realistically, if, say, one of these big corps/banks with deeply-integrated COBOL systems spent a few years revamping their systems to something more modern and usable today, how much would it cost? What language would you suggest? Remember that decimal reliability and predictability is important. Plus, let's pick a language likely to have a very long service life because we need to have our investment rewarded. Frankly, the iSeries machine we have is pretty cheap to run. We bought it 10 years ago for about $15k and have had a maintenance contract that doesn't cost that much (about the same as our Red Hat service contract). We probably will buy another one since they just released a sub $10k one that will more than meet our needs. Never lost any data, easy enough backup that the biz office does it themselves[1], and IBM is pretty quick about any fixes. Much cheaper than any Linux, BSD, or Windows system we have ever had. Plus, I don't mess with it like the others. It just works. 1) we've tested it multiple times, after all, an unrestored backup is not a true backup
- scrollaway 9y ago
  I don't know enough about these systems to suggest a language, but I imagine within the "a few years of development" is budgeted some time to figure out what tool to use. Surely you're not telling me that mainframes running COBOL is the best tool for the job. What languages do younger banks use?

badloginagain 9y ago

That also provides a vector for experienced COBOL devs to make _serious_ money as instructors. Banks would fly out trainees anywhere on the planet for any fee if it meant critical systems have the necessary ops guys. It's also a great proposition for a grad student. They don't have to unlearn much, they're in a perfect position to absorb a new language, and the term 'set for life' can be thrown around liberally. Wouldn't be surprised if this was already a thing, probably in the form of COBOL-specific Consultation services.

braymundo 9y ago
There is: http://cobolcowboys.com/ http://cobolcowboys.com/

f4rker 9y ago

"The idea that large corporations are simply going to move on from COBOL is out of touch with reality" Thank you. So much internet arm chair analysis falls into this category.

lowken10 9y ago
The company I work for has piles of Visual Basic 6 code that will be here for as long as their product is viable (Prepaid credit cards services). The growth is simply not their to perform a rewrite. It's sad but is also a reality.
- Koshkin 9y ago
  I clearly remember VB6 being an excellent tool. Quality of code varied widely between developers.
  - shepardrtc 9y ago
    VB6 was incredibly easy to work with, and honestly, the value it provided by being able to link a quickly-made, solid UI with easy, solid code was highly underrated.
    - noir_lord 9y ago
      Same with Delphi which had a better underlying language than BASIC, fast compiles, superb version support and a stunning VCL (visual component library), it took VS studio years to catch up with a lot of that.

woliveirajr 9y ago

I don't understand why there wouldn't be at least 2 or 3 students, in any graduation class, interested in learning some language (and everything around it, since COBOL isn't just about the language but understanding business and computation in another paradigms). Do all students just care about learning the hype and creating the next flapping bird game?

cafard 9y ago
A sometime co-worker, probably in his late 20s, emailed me from the Data Science bootcamp he was attending to ask a question about COBOL. He is not interested himself, but somebody else in the class has heard that it pays well. I gave him what I thought was the email for our shop's last (now retired) COBOL guru, and recognized GNUCobol as a place to start.
lovich 9y ago
When I first started getting into development I took a look at it because I heard of the great money you could get if you were an expert in it. From what I could tell at the time, 5-6 years ago, it was both a lot harder work to even learn anything more modern just due to the lack of a community that had put all of their knowledge online and a risky proposition. The money looked good, but you severely limited the number of places you worked and if the industry ever decided to get off its ass and change over in even low double digit percentages you were likely to be out of work and with skills that didnt really transfer
jetti 9y ago
I was interested in COBOL while doing my MS in CS (coming from non-CS undergrad) but the problem was tooling and projects. I gave up after trying to track down z/OS, install hercules and get all that tooling set up. There is more to learning development on these old applications than just COBOL though, you need JCL and other applications/tools that go along with it. I ended up giving up because it just became too much of a hassle. Creating a new flapping bird game is exciting for students because it can give them an opportunity to create something from nothing. You aren't going to get that opportunity doing COBOL development. You will most likely spend the rest of your career doing maintenance work rather than any greenfield development. There is nothing wrong with that but not everybody likes the fact they can't create something new.

amorphid 9y ago

Object oriented COBOL is actually a thing now :)

cafard 9y ago
It has been for a while. Probably it was last year when we threw out a bunch of Microfocus Object COBOL documentation acquired about 1987. Let me add that I know essentially nothing about COBOL.

lithos 9y ago

They already do this. At my old tech school there was almost a rotation of COBOL/RPG instructors back and forth between the schools/businesses. Along with those businesses paying for some of their own to go through the classes. Other companies have worked together to essentially make boot camps before SV even thought to do so.

mamcx 9y ago

> the money to do the change simply wasn't there. This is a good excuse for a few years. But after decades? And talking about banks? --- The whole software industry is frankly pathetic. We are talking about actors with the HIGHEST profits of mankind, and yet "we don't have money for this" star to look pathetic. Google, Apple, MS, IBM, Oracle, Banks, Defense industry, etc have not excuse to not invest in basic infrastructure. This is the same thing with country that neglect self-investment in fundamentals. If you agree is smart to invest in road, electric grid, etc, then why we think otherwise when we talk about OUR industry.?

wahern 9y ago
Talk is cheap and rarely includes a full accounting of real-world constraints. You can tell what a person's _real_ priorities are by what they do. Likewise, you can tell what a society's real priorities are by what they do.
- mamcx 9y ago
  >Talk is cheap and rarely includes a full accounting of real-world constraints. Of course. But after decades of the same problem, is not time to admit that is time to change?
  - wahern 9y ago
    Everybody always complains about the weather but nobody ever does anything about it. In other words, even though everybody complains about something, and even though it's theoretically fixable, the cost+benefit isn't always there. That doesn't stop people from complaining or offering conceptual solutions. If nobody pursues a particular solution, that's strong evidence about the real implementation and problem costs. Not conclusively, of course. But as a passive observer it's usually the best evidence available. Really, the answer to the COBOL "problem" is obvious and it's what basically anybody familiar with it suggests: a piecemeal and gradual shift according to cost, benefit, and opportunity.
nikdaheratik 9y ago

manyxcxi 9y ago

A project I lead at least ten years ago was all about moving a company away from a COBOL based system- huge piles of money were an option and the timeline was in the 3-5 year range, and still everyone (myself included) thought there were better options all around. The driving factor was a suite of new services and features they wanted to implement, we came up with a creative way to run parts of the system as proxies to the COBOL applications backing them and to decorate the requests and responses with data from the newer systems. We were done much faster and cheaper, for a project of its scope there were surprisingly few hiccups or post launch rework projects, and we got the end result they could've spent 10x the money to achieve- and all with way lower risk. I'm assuming we were in a fortunate position that the general flow of data could be handled from the various source streams, but I wonder why this isn't at least an option for moving forward from some of these ancient systems. It seems like a good first step, at least.

arvinsim 9y ago

But something has got to give down the road, right? I feel sorry for the future guy who will be forced by circumstances to do the change.