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

51–59 of 59 posts

Re: Why COBOL Isn't the Problem

#51

Post by nonameiguess »

watertom wrote: post #23

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 engi…

This is about government, though. Nothing except tax collection and certain police activities are a source of revenue. That is the entire point of government. They're not doing things intended to make money or get rewarded by Wall Street.

Re: Why COBOL Isn't the Problem

#52

Post by wtetzner »

opsunit wrote: post #31
wtetzner wrote: post #24

Earlier quoted context omitted.

> 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"?

Having worked on the PL/1 and Assembler that formed the core accounting systems of a bank: yes. Not only did I have source control I had flow diagrams of the entire system for all points in the chain. My code reviews had me doing line-by-line justifications. I wrote tests. Just because the technology and practitioners are old it doesn't mean they don't know what they're doing. Generally they invented whatever "you" a…

> Just because the technology and practitioners are old it doesn't mean they don't know what they're doing.

I certainly didn't mean to imply that. It's more that many people now don't do a good job with that stuff, so I was curious if it would have been better then.

Re: Why COBOL Isn't the Problem

#53

Post by znpy »

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.

a long streak of dumb decisions made by upper management (think C-level execs, not direct managers).

Re: Why COBOL Isn't the Problem

#54

Post by znpy »

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.

you're pretty much right.

Re: Why COBOL Isn't the Problem

#55

Post by znpy »

zimpenfish wrote: post #30
jgeada wrote: post #28

Earlier quoted context omitted.

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.

It really depends. where the scene is not that big, it does happen to meet again a former coworker (or a former boss) at another company.

I've seen that happen.

Re: Why COBOL Isn't the Problem

#56

Post by znpy »

tl wrote: post #27
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.

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.

This is also true.

Re: Why COBOL Isn't the Problem

#57

Post by coldtea »

kimi wrote: post #45
opsunit wrote: post #31

Earlier quoted context omitted.

Having worked on the PL/1 and Assembler that formed the core accounting systems of a bank: yes. Not only did I have source control I had flow diagrams of the entire system for all points in the chain. My code reviews had me doing line-by-line justifications. I wrote tests. Just because the technology and practitioners are old it doesn't mean they don't know what they're doing. Generally they invented whatever "you" a…

COBOL was used for more mundane tasks - a lot of data loading, formatting, batches of all kinds. Not all of which seemed so important when they were written, but that ended up being a plug nobody wants to take the risk of disconnecting.....

If they're still run, they're still important if not crucial.

I don't think they do data loading and batch processing on stuff they don't need.

Re: Why COBOL Isn't the Problem

#58

Post by kimi »

coldtea wrote: post #57
kimi wrote: post #45

Earlier quoted context omitted.

COBOL was used for more mundane tasks - a lot of data loading, formatting, batches of all kinds. Not all of which seemed so important when they were written, but that ended up being a plug nobody wants to take the risk of disconnecting.....

If they're still run, they're still important if not crucial. I don't think they do data loading and batch processing on stuff they don't need.

Exactly. But sometimes they were built as a "quick patch, we'll do this right later" and then improved and changed and.... you see the picture.

Re: Why COBOL Isn't the Problem

#59

Post by brogrammernot »

marktangotango wrote: post #39
brogrammernot wrote: post #21

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…

>> 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”. Wrong, there are literally 10,000s of former cobol developers due to decades of offshoring. I know of several thousand in from one local company alone. Go look for these job listings, you won't find them because they're all offshore.

Offshore isn’t a realistic solution, the quality & language barriers that come into play significantly slow down any sort of production cadence compared to in-house.
Post reply on HN