Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why COBOL Isn't the Problem

lucidchart.com

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Why COBOL Isn't the Problem

#21

Post by brogrammernot »

My father has been working in COBOL since the 80s, and his “reference” books are literally a couple of 4” 3 ring binders that he’s assembled over 40 years now of coding.

Everytime the bank tries to switch away from COBOL they run into problems ranging from code latency to lack of support for certain features in the new language among other issues thus far.

I really don’t know what the banks that run cobol mainframes are going to do as most have ignored the Father Time problem where cobol programmers aren’t getting any younger and the language, in my opinion, is miserable compared to the “magic” of newer era languages.

My pops also has made less money then I did as an engineer at a tech co with 3 years experience so banks aren’t valuing the work these folks do very much either.

I’ve told my pops he can do consulting once he retires and make a killing because there’s gonna be a major shortage of cobol folks and a massive amount of mainframe code out there that needs maintenance or a transition into a newer era language.

Edit: - The author is wrong here

“If you need to change old programs, hiring experienced programmers and teaching them COBOL is the cheap part.”

There is not a surplus of developers or entry level folks willing to learn cobol over another entry level language, so it’s not cheap and it’s not “easy”.

Re: Why COBOL Isn't the Problem

#22

Post by goatinaboat »

yawaworht1978 wrote: post #20

Are the cobol devs from the past the equivalent of the modern day vbs and excel script persons?

Are the cobol devs from the past the equivalent of the modern day vbs and excel script persons?

No, they were writing the typical corporate applications - an interface to enter data into a database, or to run a query and generate some nicely formatted output. They were the equivalent of a modern day webdev.

Re: Why COBOL Isn't the Problem

#23

Post by watertom »

The problem is maintenance, it's a cost center, it doesn't directly generate revenue, so it's been eliminated.

NOBODY is willing to spend money for maintenance on ANYTHING, look at our infrastructure.

If it wasn't for the FAA making it illegal to not maintain planes, we'd be seeing the same thing with airlines and their planes.

We are seeing this with the Air Force right now, where they are now trying to reverse engineer parts for planes and then 3d print those parts, because no one was willing to spend the money to maintain documentation, maintain vendors, and parts inventory, etc.

Software is especially vulnerable to this phenomenon, because it's not physical so it's considered to be completely fungible, but in fact it's even harder to maintain than physical systems.

The same way Wall Street rewarded companies that closed factories, and outsourced physical locations, and staff, they've also rewarded companies that have eliminated maintenance.

That's just the way it is.

Re: Why COBOL Isn't the Problem

#24

Post by wtetzner »

kimi wrote: post #17

There are a few things that the author forgot: - COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why. - COBOL programs do what they do. They do not have specs, but if that's the way we have been computing account interests for the last 50 years, they are right. It's lawyers documenting them, not the other way around. - COBOL…

> COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why.

I wonder how different it would be if they had a good source control system (and used it). Would you be able to look at the history and understand why the changes were made, or would you just get a bunch of commit messages like "made update" or "reverted earlier change"?

Re: Why COBOL Isn't the Problem

#26

Post by goalieca »

wtetzner wrote: post #24
kimi wrote: post #17

There are a few things that the author forgot: - COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why. - COBOL programs do what they do. They do not have specs, but if that's the way we have been computing account interests for the last 50 years, they are right. It's lawyers documenting them, not the other way around. - COBOL…

> COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why. I wonder how different it would be if they had a good source control system (and used it). Would you be able to look at the history and understand why the changes were made, or would you just get a bunch of commit messages like "made update" or "reverted earlier change"?

Imagine they used jira, confluence, and git. It would still be a huge no! Code archeology is a real necessity even on a <10 year old system. The best way to find out about something is to have a chat with a ‘historian’ who has been with the company for 10+ years.

Re: Why COBOL Isn't the Problem

#27

Post by tl »

dunefox wrote: post #14
znpy wrote: post #5

Earlier quoted context omitted.

> If more of us grew a spine, we wouldn't see the management/IT-ops staging a recreation of the stereotypical high-school jocks/nerds conflict. I cannot upvote this enough. I haven't seen a company change mind so fast until 3/4 of a huge team (25-30 people) team left the company within 6-8 months.

What made them leave? It's different if they leave randomly or because a well known set of reasons.

Finding a job with higher pay or a better work environment makes the rest of that team (and possibly members of other teams) reconsider staying.

Personal anecdata: one person leaving a team of 10-20 caused 3-5 other people to either leave or re-negotiate in private. In extreme cases, this triggers a chain reaction.

Re: Why COBOL Isn't the Problem

#28

Post by jgeada »

dunefox wrote: post #14
znpy wrote: post #5

Earlier quoted context omitted.

> If more of us grew a spine, we wouldn't see the management/IT-ops staging a recreation of the stereotypical high-school jocks/nerds conflict. I cannot upvote this enough. I haven't seen a company change mind so fast until 3/4 of a huge team (25-30 people) team left the company within 6-8 months.

What made them leave? It's different if they leave randomly or because a well known set of reasons.

Everybody lies on exit interviews. You mostly don't want to burn bridges and frequently will need some references. So HR departments have 0 useful information as to why people are leaving and even less about the costs of having developers go.

Re: Why COBOL Isn't the Problem

#29

Post by BitwiseFool »

wtetzner wrote: post #24
kimi wrote: post #17

There are a few things that the author forgot: - COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why. - COBOL programs do what they do. They do not have specs, but if that's the way we have been computing account interests for the last 50 years, they are right. It's lawyers documenting them, not the other way around. - COBOL…

> COBOL programs have history. They were changed in '77 and then the change was reverted in '79 and then again in '84. Nobody really remembers why. I wonder how different it would be if they had a good source control system (and used it). Would you be able to look at the history and understand why the changes were made, or would you just get a bunch of commit messages like "made update" or "reverted earlier change"?

In my professional experience, code comments and commit messages only cursorily reflect the change in the business logic that prompted the modifications. I suspect this is because the knowledge of the client's business logic is concentrated in the product managers' domain and not in the programmers' domain. All of the back and forth emails with the customer don't get included in our SCM.

Re: Why COBOL Isn't the Problem

#30

Post by zimpenfish »

jgeada wrote: post #28
dunefox wrote: post #14

Earlier quoted context omitted.

What made them leave? It's different if they leave randomly or because a well known set of reasons.

Everybody lies on exit interviews. You mostly don't want to burn bridges and frequently will need some references. So HR departments have 0 useful information as to why people are leaving and even less about the costs of having developers go.

> Everybody lies on exit interviews. You mostly don't want to burn bridges

Hold on - not everyone does (I offer myself as anecdata). And I am more than happy to burn bridges if I'm leaving a toxic workplace because, well, it's toxic.

Post reply on HN