Well, Indian offshore companies have been training many COBOL guys since Y2K. These days, most of the SAP related jobs are outsourced to India. How can one expect that the same fate won't befall those who want to master COBOL now?
> How can one expect that the same fate won't befall those who want to master <insert any language here>
FTFY.
No programming language requires proximity. The only jobs you can expect to never be offshored are in (literal) plumbing.
This said, anything involved with Very Big Companies is probably more at risk, because it makes more sense for them to move entire departments offshore just to save a few percentage points on aggregate costs (actual productivity be damned). So I expect this will soon happen to the likes of Salesforce, if it's not already. AWS is definitely already happening.
Also anything getting too mainstream, because then it makes sense for outsourcers to invest in training high numbers of people. I expect the market to soon be flooded by Python outsourcers, now that it's making real inroads in the enterprise space (with bigdata etc).
Can confirm, I live in the capital city of an Eastern European country and I've been approached by a AWS recruiter a couple of months ago, she told me they were about to open a big new office in here. I think they were quite desperate to get their share of hirings because they had approached me even though there was no mention on my LinkedIn profile of C++ or Java, which was a major part of the job requirements.
> I expect the market to soon be flooded by Python outsourcers,
Fortunately or not there aren't that many Python programmers out here to speak of (I'm talking about Eastern Europe, maybe things in India and South-East Asia are different). I should know, because I've been programming Python for a living for 13 years now and the market for Python programmers isn't a large one. Yeah, I did ok, as in there are small shops that pay decent money for Python programmers, and from time to time there's even a big outsourcing company desperate to hire Python programmers because a new foreign client has arrived with a Python project on their doorsteps, but more often than not Python is still looked as a "scripting language" and as a "programming language for non-important and non-enterprisey stuff".
Just recently a friend of mine that used to work for a major outsourcer based in this area (they have big Western clients, you probably interact with some of their code each day) told me that their company puts people like Python programmers that they intend to hire on a special list (and probably Ruby programmers, too), as in they're not seen as long-term employees, more like project-based (see the part above about Python projects coming from foreign clients), as the focus is mostly on Java and probably some C# and C++, but mostly Java.
I’m curious why there aren’t more x -> x conversion/adapter tools available. Most languages have the same core data models/abstract concepts, if there really is an enterprise/business demand for a product, usually some company would come up with a solution. Personally I’m curious about COBOL and learning from it’s design, but I’m intrigued by this question in general.
The conversion/adapter tools exists. It's not a technical issue.
The problem is that cobol applications are normally monolithic, and a migration to another system represents an huge risk because:
1) you migrate like a Big Bang migration, or;
2) you migrate step by step.
Imagine a bank with applications running at 30 or 40 years without problems... Nobody in his perfect judgment will accept to have a Big Bang migration. The risk is too high.
For migrating step by step, you must have a good bussiness case (it must compensate the risk), opportunity (you must be able to keep working in the Bussiness As Usual) and you must have the right people (people that have the knowledge in organization). If you don't have this three things it will be very hard to migrate Cobol to another language/platform.
Usually Cobol is used in mainframe, so the right aproach (with less risk) IMHO is to migrate first COBOL from z/os to a Cobol in another platform (windows/*nux whatever), and then migrate Cobol gradually to another language.
There can also be an intermediate phase of migrating from a hardware mainframe to a virtualized mainframe. I understand that's what TicketMaster did a while ago.
> Most languages have the same core data models/abstract concepts
There was a post on here not too long ago about COBOL's decimal arithmetic -- if you're not careful, your Java / Python / Ocaml is going to give you different numbers. So on the "core data model" front, there's more than meets the eye. Add to that the barrier to entry of working on mainframes: even if you install an emulator and play around with COBOL, you don't have a big COBOL codebase to work with, so you have no idea what you're going to see in a production system that was written 45 years ago.
Not that I really believe we're headed for a COBOL crisis. COBOL systems will no doubt continue to rust in place and eventually reach irrelevance as they're decommissioned one by one during horribly mismanaged bank mergers. The exception is the federal government of the U.S., which will surely continue operating its COBOL systems until the end of time.
There is likely more to solve than just code. COBOL is often running in a proprietary environment with dependencies on things like job schedulers, databases, terminals, network protocols, character sets, etc.
Check the COBOL job postings, and you'll see desired skills in TSO, JCL, CICS, Natural/Adabase, VSAM, etc. Or equivalents of those for OS/400, MPE, or VMS mid-range platforms.
> The problem is that Cobol isn’t popular with new programmers.
Enough with the COBOL shortage myth. Don't be fooled, not being popular is not the problem. The problem is COBOL jobs aren't competitive, they often even pay worse than other tech jobs. That's why they are either being outsourced or offered to 60 year olds in their spare time. (So arguably they're not that mission-critical, either.)
But then who is writing articles with a false premise and why? Why would a news outlet (and I use that term loosely) even feature an article that ostensibly is to get more programmers to do COBOL cheaper? I don't even understand the agenda here - is there some kind of meta-game? The best I can think of is they're hedging their bets for when a bank fucks up, but even that seems pathetic. Maybe it's just COBOL turns out to be great clickbait for programmers.
That's a little too simple. The basic fact is they have consistent and helpful sources who put a nice little bow on an easy-to-write story that nobody will really object to.
Maybe the author of the article browses HN and/or Reddit and saw some comments about there being few COBOL programmers (I've seen a couple of comments about it in the past), and decided to write an article about it?
Just more “evidence” to support the long running Shortage Of Engineers™ narrative. Just because the topic is COBOL doesn’t mean it’s not a submarine promoting all the usual things like outsourcing, more H1B visas, and over-saturation of STEM graduates.
There have been enough of these stories over the years that literally the only item of interest is likely to be the author's bio:
Max Colchester is a U.K. banking correspondent for the WSJ in London. Previously WSJ correspondent in Paris covering fashion, nuclear energy and politics. He is @MaximColch on Twitter.
So the main thing is, the author - because of his background - likely has no idea that this is a recurring theme over decades, that the world nevertheless hasn't run out of COBOL programmers, and that it's an IT job companies today are as likely to outsource to the lowest bidder as any other job (whether that's a good idea or not).
I can't tell if this is in the article as it's paywalled, but a company in York recently put up an advert for £20k/year for Cobol programmers with no programming experience required, doubling at the end of the training period.
£400 a week, in York? Hell yes. £800 once you’re done training for someone who couldn’t program before they started is not just good, it’s fantastic for anywhere in the U.K. outside London for a junior.
I'm not sure if you are being tongue-in-cheek or not, but it's at least a workable idea. Outsourcing in my experience is an almost unredeemable shitshow, with far, far more misses than hits, but going the cheapest possible route is much more expensive in the long run. The timeshift between US and British working hours is a lot more convenient, if nothing more.
People absolutely are - one of my previous employers moved a large development team to Belfast, and another team has a team in Dublin (not the UK, but presumably their rates aren't too wildly different.)
£20k for a 21 y/o would be good, more than many entry office jobs. And jumping to £40k would put you ahead of many office and other roles that 30+ y/o might hope to get (more than a local teacher with a few years of experience for example). Yes there are some higher paying jobs in the area - but if you are looking for a first role fresh out of uni - that would be pretty good. Exp if no experience needed.
I'm not sure from grandfather's post whether the candidates would be expected to be computing graduates or not.
In the UK, £20k is below average for a junior programmer straight out of university. For example, we've just employed such a person for £25k, in a PHP role.
However, the jump to £40k, provided that the qualifying period wasn't too long, would shortcut several years of career development for a recent graduate. I'd say that's a good deal, except that I'd be concerned about the long term prospects for a COBOL programmer in the UK.
I really dislike slotting things down to a language. If you are proficient in the underlying programming concepts, the language simply does not matter with the right amount of motivation.
Of which part? That a programmer can learn another language, or that Linear A isn't just an obscure programming language written down with stick on clay bricks?
Yeah, I don't think it'd be that big of a stretch. I knew someone about 25 years ago who went from creating applications in visual basic, to working on device drivers (often involving assembly). There's a learning curve obviously, but working in assembly and working in js have plenty in common.
The biggest problem going from PHP to Assembly is going to be the jump from presumably-web-pages to presumably-hardware programming.
The mechanics of the language will be a very minor speed hump compared to changing problem domains. You can signal for that with specific programming languages, but realistically a hiring manager should be most interested in finding someone who understands the core concepts of the problems at hand rather than any specific language.
If solving a problem implies directly accessing a CPU register then realistically that part of the problem is going to get solved using Assembly. If twiddling bits on the CPU isn't needed then other languages will just be faster to move from nothing -> problem solved -> solution in maintenance mode so Assembly should be avoided. This decision doesn't really hinge on the programmers preferences.
Yes, someone with a strong competency developing software in any language should be able to learn to write Assembly/any other language. There will be a learning curve, but the ability to reason abstractly is fully transferable.
I'd presume that anyone with a BS in computer science should be able to write assembly for at least one RISC architecture.
I'd also presume that more companies would ask them to do so than those who have legitimate business reasons to write something in assembly. We are long past the age of resource-constrained architecture hacks. The closest most people should be getting to metal is ANSI/ISO C, and the others are all writing compilers or doing extreme optimization stunts.
Can I write in assembly? Yes. Should I write in assembly? Hell no.
Those companies that still require COBOL/mainframe programmers have had literally decades to watch the center of mass of the software industry move away from that, and then still make a conscious decision to pursue a dead-end path to obsolescence.
The missing link here is that COBOL is being used as shorthand for experience with mainframe programming, which of course you can’t really get unless you’ve been employed programming mainframes before. Anyone complaining about a lack of COBOL programmers is essentially complaining that nobody else is picking up on the training costs for their non-standard, incredibly expensive infrastructure, and that they don’t want to train people themselves.
Replying to the title here, but from my experience knowing how to program COBOL was only one small part of the problem at my previous employer. Knowing what the programs where doing and what other programs the output affected mattered much more. Such knowledge was not set in documentation but rather in people's heads, more often than not that knowledge disappeared as soon as the person that had been working in that part of the system retired.
It's the business knowledge that really matters. I think this is true no matter what languages and toolsets are used-- in the end, it turns out to be the surrounding information that's of value.
I could learn COBOL; I've had to take classes in my undergrad and one of my careers involved it. There's a couple of reasons why I dont:
* Putting my career on a trajectory where I am using a dying technology. Unless it paid 3x-5x what I could make using a JVM language (my current career path), the risk/reward isn't there. So market forces will need to drive the cost of salaries up even farther before I consider a jump.
* Outdated development methodologies. My experience with COBOL so far is a lot of entrenched practices that we later learned are inefficient. Both tools and management have been extraordinarily reluctant to improvement and change. I'm not willing to undertake the additional stress to deal with PITA, so until the management over these ares is forced into retirement, companies will endure a shortage of fresh talent.
I made the explicit choice to avoid the COBOL trajectory in 2001 when I graduated from college. At the time the place I graduated from was working hard to graduate people with skills for the local industry (which was cobol, jcl, rpgIII, etc)
I don’t blame the college. But it was a choice and for me it was a good one.
Another issue with COBOL (Apart from being unsexy and verbose) is simply getting access to a proper mainframe environment. You could pick up COBBOL using something like GNU Cobol or similar but it's working in the z/OS environment that is needed and understanding the various system facilities and how they interact. MTM is pretty much one of the only ways to get access to a recent version of z/OS to test on (the other being shelling out 2K/yr for IBM LMS access).
In a age when most things come with snazzy oneliners and docker images trying to learn COBOL is an esoteric endevour. The language has its warts and quirks, but it's nothing too crazy. Same with TSO and learning JCL, it's orthogonal to the current landscape.
(Not saying I wouldn't love to be doing in here in Canada)
Fun fact: The current version of IBM Cobol has JSON GENERATE and JSON PARSE, so you can whip up endpoints that interact directly with a mainframe (as long as your convert the code page at the network boundary). Never thought I'd be able to use React and Cobol backed by DB2 in 2018.
Another thing is that the mainframe vendors use their locking to get a lot of money. So some companies want to leave that, except they can't because the business logic written in COBOL works well. Therefore, the company let most of its COBOL workforce go, keep some old guys to maintain programs and divert investment to other platforms. When the old maintenance crew will be dying, businesses will have had time to move out of the mainframe. That's what I see at a few government agencies in my country : COBOL is still alive, but it's just slowly dying and nobody invest in it anymore. And the jobs associated to it are labelled as "maintenance", good luck getting a pay rise.
Tips : Oracle feels the same, we're moving to Posgtresql wherever possible. So my career path is basically set : Java will stay on top because there's no language that is better in my segment (batch processing, long lived code, just a hell of a business logic, thousands of rules) and Oracle will be pushed out by in place replacement like postgres. I'm gonna die in an open source world :-)
53 comments
[ 16.3 ms ] story [ 1919 ms ] threadHow about salaries?
FTFY.
No programming language requires proximity. The only jobs you can expect to never be offshored are in (literal) plumbing.
This said, anything involved with Very Big Companies is probably more at risk, because it makes more sense for them to move entire departments offshore just to save a few percentage points on aggregate costs (actual productivity be damned). So I expect this will soon happen to the likes of Salesforce, if it's not already. AWS is definitely already happening.
Also anything getting too mainstream, because then it makes sense for outsourcers to invest in training high numbers of people. I expect the market to soon be flooded by Python outsourcers, now that it's making real inroads in the enterprise space (with bigdata etc).
Can confirm, I live in the capital city of an Eastern European country and I've been approached by a AWS recruiter a couple of months ago, she told me they were about to open a big new office in here. I think they were quite desperate to get their share of hirings because they had approached me even though there was no mention on my LinkedIn profile of C++ or Java, which was a major part of the job requirements.
> I expect the market to soon be flooded by Python outsourcers,
Fortunately or not there aren't that many Python programmers out here to speak of (I'm talking about Eastern Europe, maybe things in India and South-East Asia are different). I should know, because I've been programming Python for a living for 13 years now and the market for Python programmers isn't a large one. Yeah, I did ok, as in there are small shops that pay decent money for Python programmers, and from time to time there's even a big outsourcing company desperate to hire Python programmers because a new foreign client has arrived with a Python project on their doorsteps, but more often than not Python is still looked as a "scripting language" and as a "programming language for non-important and non-enterprisey stuff".
Just recently a friend of mine that used to work for a major outsourcer based in this area (they have big Western clients, you probably interact with some of their code each day) told me that their company puts people like Python programmers that they intend to hire on a special list (and probably Ruby programmers, too), as in they're not seen as long-term employees, more like project-based (see the part above about Python projects coming from foreign clients), as the focus is mostly on Java and probably some C# and C++, but mostly Java.
COBOL in Indian offshore companies is often a shorthand for Mainframe experience. And many people do Java on Mainframes along with COBOL.
>>These days, most of the SAP related jobs are outsourced to India.
Been happening since more than a decade. You could point to any random tech, and some one in an big IT offshore firm will be working on it.
>>How can one expect that the same fate won't befall those who want to master COBOL now?
What fate? Until a while ago, mainframe skills were one of the most important ones in the industry.
>>How about salaries?
If you work for somebody through a third party contracting firm, your salary is going to be low. Not just if you do COBOL, but any tech.
The conversion/adapter tools exists. It's not a technical issue.
The problem is that cobol applications are normally monolithic, and a migration to another system represents an huge risk because: 1) you migrate like a Big Bang migration, or; 2) you migrate step by step.
Imagine a bank with applications running at 30 or 40 years without problems... Nobody in his perfect judgment will accept to have a Big Bang migration. The risk is too high.
For migrating step by step, you must have a good bussiness case (it must compensate the risk), opportunity (you must be able to keep working in the Bussiness As Usual) and you must have the right people (people that have the knowledge in organization). If you don't have this three things it will be very hard to migrate Cobol to another language/platform.
Usually Cobol is used in mainframe, so the right aproach (with less risk) IMHO is to migrate first COBOL from z/os to a Cobol in another platform (windows/*nux whatever), and then migrate Cobol gradually to another language.
> Hi! First post on here.
Welcome, and very nice post. :)
There was a post on here not too long ago about COBOL's decimal arithmetic -- if you're not careful, your Java / Python / Ocaml is going to give you different numbers. So on the "core data model" front, there's more than meets the eye. Add to that the barrier to entry of working on mainframes: even if you install an emulator and play around with COBOL, you don't have a big COBOL codebase to work with, so you have no idea what you're going to see in a production system that was written 45 years ago.
https://news.ycombinator.com/item?id=17636029
Not that I really believe we're headed for a COBOL crisis. COBOL systems will no doubt continue to rust in place and eventually reach irrelevance as they're decommissioned one by one during horribly mismanaged bank mergers. The exception is the federal government of the U.S., which will surely continue operating its COBOL systems until the end of time.
Check the COBOL job postings, and you'll see desired skills in TSO, JCL, CICS, Natural/Adabase, VSAM, etc. Or equivalents of those for OS/400, MPE, or VMS mid-range platforms.
Enough with the COBOL shortage myth. Don't be fooled, not being popular is not the problem. The problem is COBOL jobs aren't competitive, they often even pay worse than other tech jobs. That's why they are either being outsourced or offered to 60 year olds in their spare time. (So arguably they're not that mission-critical, either.)
But then who is writing articles with a false premise and why? Why would a news outlet (and I use that term loosely) even feature an article that ostensibly is to get more programmers to do COBOL cheaper? I don't even understand the agenda here - is there some kind of meta-game? The best I can think of is they're hedging their bets for when a bank fucks up, but even that seems pathetic. Maybe it's just COBOL turns out to be great clickbait for programmers.
Usually you see more of this on non-mainstream topics or stories that don't get much traction because there will be no backlash.
In this case it's almost too obvious whom the press release was sent out on behalf of ("Cobol Cowboys").
Max Colchester is a U.K. banking correspondent for the WSJ in London. Previously WSJ correspondent in Paris covering fashion, nuclear energy and politics. He is @MaximColch on Twitter.
So the main thing is, the author - because of his background - likely has no idea that this is a recurring theme over decades, that the world nevertheless hasn't run out of COBOL programmers, and that it's an IT job companies today are as likely to outsource to the lowest bidder as any other job (whether that's a good idea or not).
(Being paid to learn a skill from scratch does sound pretty objectively good, though.)
In the UK, £20k is below average for a junior programmer straight out of university. For example, we've just employed such a person for £25k, in a PHP role.
However, the jump to £40k, provided that the qualifying period wasn't too long, would shortcut several years of career development for a recent graduate. I'd say that's a good deal, except that I'd be concerned about the long term prospects for a COBOL programmer in the UK.
I'm not saying you're wrong, but I feel like there's a piece there that's missing.
Assembly isn't Linear A.
COBOL? :)
The mechanics of the language will be a very minor speed hump compared to changing problem domains. You can signal for that with specific programming languages, but realistically a hiring manager should be most interested in finding someone who understands the core concepts of the problems at hand rather than any specific language.
If solving a problem implies directly accessing a CPU register then realistically that part of the problem is going to get solved using Assembly. If twiddling bits on the CPU isn't needed then other languages will just be faster to move from nothing -> problem solved -> solution in maintenance mode so Assembly should be avoided. This decision doesn't really hinge on the programmers preferences.
I'd also presume that more companies would ask them to do so than those who have legitimate business reasons to write something in assembly. We are long past the age of resource-constrained architecture hacks. The closest most people should be getting to metal is ANSI/ISO C, and the others are all writing compilers or doing extreme optimization stunts.
Can I write in assembly? Yes. Should I write in assembly? Hell no.
Those companies that still require COBOL/mainframe programmers have had literally decades to watch the center of mass of the software industry move away from that, and then still make a conscious decision to pursue a dead-end path to obsolescence.
It's the business knowledge that really matters. I think this is true no matter what languages and toolsets are used-- in the end, it turns out to be the surrounding information that's of value.
That pays just over minimum wage.
* Putting my career on a trajectory where I am using a dying technology. Unless it paid 3x-5x what I could make using a JVM language (my current career path), the risk/reward isn't there. So market forces will need to drive the cost of salaries up even farther before I consider a jump.
* Outdated development methodologies. My experience with COBOL so far is a lot of entrenched practices that we later learned are inefficient. Both tools and management have been extraordinarily reluctant to improvement and change. I'm not willing to undertake the additional stress to deal with PITA, so until the management over these ares is forced into retirement, companies will endure a shortage of fresh talent.
I don’t blame the college. But it was a choice and for me it was a good one.
In a age when most things come with snazzy oneliners and docker images trying to learn COBOL is an esoteric endevour. The language has its warts and quirks, but it's nothing too crazy. Same with TSO and learning JCL, it's orthogonal to the current landscape.
(Not saying I wouldn't love to be doing in here in Canada)
Fun fact: The current version of IBM Cobol has JSON GENERATE and JSON PARSE, so you can whip up endpoints that interact directly with a mainframe (as long as your convert the code page at the network boundary). Never thought I'd be able to use React and Cobol backed by DB2 in 2018.
Tips : Oracle feels the same, we're moving to Posgtresql wherever possible. So my career path is basically set : Java will stay on top because there's no language that is better in my segment (batch processing, long lived code, just a hell of a business logic, thousands of rules) and Oracle will be pushed out by in place replacement like postgres. I'm gonna die in an open source world :-)
I started with COBOL. If the freelance gigs continue on, maybe I'll wind down my career with a little part-time, once-in-a-while COBOL work.
It might just be nostalgia, but I miss that environment a little bit.