Hacker News Reader

Comment by ams6110 | Hacker News Reader

The COBOL programmer shortage is solvable if they simply pay people enough money. COBOL programmers do not make SV salaries, far from it. Yet the code they write generally is handling more critical tasks than most of the stuff SV startups are producing (bank balances, payroll, insurance claims, etc.)

Though I found it to be stifling, I would work with mainframes again if the price was right.

View on HN

The problem isn't money as such, there are certainly very very good salaries to be made if you're an experienced COBOL developer (I don't know where you picked up the opposite idea from).

The problem is training new developers: you won't get experience developing COBOL (not just the language, but the toolchain, the idioms of the time etc) without developing COBOL, and nobody is going to let you touch the system until you're experienced.

Unlike more recent languages, there aren't a huge range of small/simpler/less important (but still representative) codebases for novices to cut their teeth on.

I think it would take some sort of apprenticeship style setup to train new COBOL devs, but that's really, really hard to get right, and will be a huge drain on the few experienced devs you do have.

It's well known that Financial companies are generally among the worst places for programmers to work. Learning COBOL just sets you up for a lot of that.

I guess it depends.

The pay is ok, the domain is interesting, and the work load is manageable.

When I look at some friends doing game development, they seem to work a lot more for a lot less. They have a cooler office though...

But I think it's a good idea to try to avoid COBOL.

Well known by whom? Sure it's Enterprise-y and you'll be in a cubicle. You'll also have a very secure position, reasonable working hours and demands, and work at a place with the financial resources to compensate you at market rate (or above).

There are a lot of places where it is a lot worse to be a programmer than a bank.

Finance is a very very broad industry. Everything from Xero to your local credit union/building society to bulge bracket investment banks fall into 'finance'. I work for a bulge bracket IB, and all of the developers enjoy their work because it's what you would expect working at a technology company; maintaining an in house document store, implementing complex mathematical models and implementing distributed graph based pricing systems for real time data are all things I've had the opportunity to do here, and everyone is payed at market rate or higher for their experience.

It's a great industry to be in if you work in the right area, just like any industry.

One of my earliest jobs was working with COBOL (I am one of the few programmers coming up in the early 2000's that had COBOL in not one, but TWO core classes required at my college). The pay was rather good for my Midwestern location, 80k+ starting base pay was well over double the average pay for college graduates.

I thought it was actually fairly interesting work. COBOL is a very neat language. Like anything though at age 22, it's not likely you'll stick around for any job, much less one where you're generally just doing maintenance and source control / corner case bug bashing. I moved on but I'll always remember the job.

Where did you attend college? I also took two COBOL courses at Miami University (Oxford) taught by a professor who preferred to be called "El Supremo". Then, in my senior year TA'd them again...thus sitting through a stunning 4 semester's worth of COBOL during the early aughts.

Didn't go there, but same state. Northern location, private school. Given Ohio, should narrow it down to about 750 different locations. :)

$80k in the early 2000s, in the Midwest, as a new grad, seems astoundingly high. That's $102-112k in today's dollars (2004/2000->2016).

It was high for sure. But others received similar offers. I graduated in 2004, so you have to adjust for that time period where tech was exploding and the economy was recovering post 9/11. Jobs were everywhere.

Oddly enough, COBOL programmer shortage is solvable if COBOL died. Banks and financial institutions are literally running COBOL code from 70s. Hundreds of millions of LOC of COBOL built from era of antiquity. The faster we move on, the better.

We are still using buildings and bridges that are more than a century old. Why should we stop using programs that work?

There is nothing wrong with using old infrastructure. However, there is something wrong with treating it as a scacred black box.

A company using ancient COBOL code should have people who understand it, but also the ability to test it, and to talk to it from new code.

Once you get to that point, replacing the COBOL is not so hard -- once you have a reason to do it.

The equivalent would probably be rather (literally) byzantine sewage and water systems from the middle ages in very old cities like Istanbul ;)

They're everywhere, they do.. something.., and nobody can replace them just all at once. Even if you replace some of them, the remaining part still means your system gets swamped by the old mess.

One reason would be that these programs crash, require updates to keep up with industry/process changes and/or will eventually be obsolete in terms of performance or process adequation.

But the knowledge required to fix or update these programs is almost completely owned by the programmers that developed them, who are in the process of retiring or are unwilling to share knowledge for (justified) fear of losing their job.

This creates an unjustifiable dependency for the company, who will have a very hard time finding senior developers to replace the original developers or even recruit <modern language> developers to build a new and more modern system. What happens to the company if the original programmers retire, get sick or leave?

Every project that I know of that focused on replacing mainframes running Cobol quickly reached nightmare-like complexity during the analysis phase - especially because the original developers were uncooperative and the scarce documentation was obsolete - and was replanned to contemplate at least twice the time (and sometimes twice the work/FTE), which will also increase the cost of replacing the technology by a few (tens of) millions...

> Every project that I know of that focused on replacing mainframes running Cobol quickly reached nightmare-like complexity during the analysis phase - especially because the original developers were uncooperative and the scarce documentation was obsolete

That has been my experience as well. It's also the case that business processes get designed around the COBOL code, not just vice versa. Separating out what are actual business requirements from "what we've always done on the mainframe" can be fiendishly difficult, and not just the original developers but the customers can be extremely uncooperative. It takes management coming in and saying "these are the new business processes, they are compliant with the industry standards, and our new software is going to implement them" to get things to actually happen. How that works for a changeover in something like a bank is beyond my experience, though.

It is much harder to modify old software than it is to modify an old building. I've seen projects to modify some small aspect of our system that took 10+ developers six months to implement, but could have been done in an afternoon by a single dev with an IDE, had the project been written in a statically typed language.

COBOL is statically typed. In fact, one of the good features about COBOL is that all fields (variables) have exactly specified lengths, including numbers. You don't just say "I want an integer", you have to say exactly how many digits are in the integer, assuming you use PIC fields (decimal) instead of COMP (binary). Non-numeric fields have exact sizes too, like X(20). It is impossible to have a buffer overflow in COBOL.

A given COBOL module is statically typed, but a typical (in my experience) COBOL application is made up of many modules and there is no type checking between them.

I'd much rather have my bank run on 45-year old COBOL code than 45-day old Go or Rust.

It is generally true. Less 'fancy' work, you get less money, irrespective of how critical your code/work is. It is an irrational element that is not necessarily driven by supply-demand dynamics.

It will take some time before they realize it though. And I find it hard that any company would pay someone who has no experience in a language boatloads of money, even if its an excellent programmer in another language.

I'm pretty sure the problem is worse than just offering money. This is why many large corporations will pay a lot more for consultants and the like rather than risk it with independent contractors, despite the contractors being much cheaper.

> And I find it hard that any company would pay someone who has no experience in a language boatloads of money, even if its an excellent programmer in another language.

Top tech employers will routinely hire you (with generous compensation packages) to program primarily in a language you're not experienced in.

Big non-tech companies are simply not set up to realize that developers are assets, not peons.

The developers in a tech-company are working at a profit-centre, generating income.

In a non-tech company, they are working in a cost-centre.

Ironically, a lot of non-tech companies have not yet realized that the services they provide are actually digital, and their profit centers are actually just a sales organisation.

It's possible to have a shortage even if companies are offering the maximum salaries they can afford.

> maximum salaries they can afford.

> bank

Uh, you would refuse to do mainframe programming for $1m/year? Seriously?

I meant the maximum amount they judge to be financially prudent. Roughly speaking, an employer will only pay an employee up to the value of that employee's work.

Based on your reply, I'm sure I don't need to explain how markets work?

I don't think so, but I also don't understand the complaint you seem to have.

"Value of the employee's work" is determined by the market. So either you can get someone cheaper or you can't. Either you can run your billion dollar banking operation without them or you can't.

When I said "value of the employee's work," I meant the financial upside to the firm for hiring a specific employee.

There is always a shortage of people willing to cut the grass with scissors for $0.05 an hour. There is always a shortage of people (for any price) capable of running a large corporation successfully. The former you don't need, so you go without. The latter you do need, so you pay what they cost.

If there is a shortage worth complaining about, it implies there is a critical need (a large financial upside -- these articles make it sound like it's an existential requirement for the bank) for hiring an employee that knows Cobol. My point is that if the compensation scaled with that critical need, plenty of people would be picking up Cobol right now, just like plenty of people are honing their business management skills.

The only users of cobol left are large corporations - they can definitely pay more to programmers. Good software engineer can pick up Cobol skills in a couple of month, six month top. We are not talking about neuorsurgent.

My impression from the article was that the barrier to entry for new hires was less the language and more the domain-specific knowledge of the industry and the institution.

Salient quote from the article: "the time before a new employee can stand on their own feet is 2–3 years"

Exactly. It is not like COBOL is that hard to learn, what is hard to learn is how these old systems work and what all the code is doing.

> We are not talking about neuorsurgent.

Most neurosurgeons just follow textbook prescriptions. I don't think this is a good analogy.

Reply on news.ycombinator.com