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

31–40 of 59 posts

Re: Why COBOL Isn't the Problem

#31

Post by opsunit »

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

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" are reinventing the first time around.

Re: Why COBOL Isn't the Problem

#32

Post by dwheeler »

The article gets it: the problem isn't COBOL, the problem is lack of maintenance. The analogy is apt, too: if you never put oil in a car & it fails, the problem is not how the car the built.

There are materials for learning COBOL. Here are some materials from the Linux Foundation's Open Mainframe project:

https://www.openmainframeproject.org/projects/coboltrainingc...

And when there was a call last year for COBOL programmers to help some of these aging systems, a lot of people immediately popped up: https://www.techrepublic.com/article/ibm-linux-foundation-se...

While COBOL has its quirks, it's not that hard to learn. It even has some advantages, for example, it has built-in support for fixed-point decimal arithmetic.

In general, COBOL is the scapegoat, not the actual problem.

Re: Why COBOL Isn't the Problem

#33

Post by theamk »

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

It depends on team culture at a time.

There are teams which require all changes come via defined channel (like bug tracker or special email), and which put ticket # in each commit (like Gitlab -- see the "closes #..." at the commit message [0])

But many teams have no procedure, or the procedure is optional -- and there you can easily get "made update" commits.

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56794

Re: Why COBOL Isn't the Problem

#34

Post by 7thaccount »

Deukhoofd wrote: post #6

I agree to some degree that learning a new language is easy, but learning a new language and understanding its intricacies that could cause issues in a program takes a whole lot longer. It takes a whole lot less time for an experienced COBOL dev to understand a program than it takes for an experienced programmer who just learned COBOL to understand it in my experience.

Not just the language, but IBM mainframes and transactions and that while ecosystem. It's not like having your Python script query a SQL database. I'm sure I could learn to write sample programs like "FizzBuzz" or "hello world" in a very short amount of time. I'm not going to be comfortable writing bank software for years.

Re: Why COBOL Isn't the Problem

#35

Post by khooke »

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

I worked at 3 different companies in the mid 1990s that had teams actively working on COBOL systems and they were all using mainframe based version control systems. I think the issue at this point is whether those version control systems are still being maintained and those orgs are continuing to pay for the licenses for those systems, probably during years where you weren't even planning on using them.

Re: Why COBOL Isn't the Problem

#36

Post by 7thaccount »

yawaworht1978 wrote: post #20

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

You can still get a lot done being a scripting guru for an organization. I view it less as a specialized role and more of something nearly all employees should be able to do now of a technical company.

Re: Why COBOL Isn't the Problem

#37

Post by nerdponx »

blowski wrote: post #16
DocTomoe wrote: post #3

Earlier quoted context omitted.

In my experience, telling them that hiring the wrong person for the job must have been their incompetence and walking out makes them reconsider their strategies quickly. Rehiring talent costs - on average - an annual salary. 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.

> Rehiring talent costs - on average - an annual salary. That's best-case scenario - an ordinary cog in a big team supporting well-documented/tested and fairly generic, simple software. A friend of mine did a research paper and said it's more like 3 years annual salary in most companies because: * Loss of productivity during notice period * Onboarding time of new staff * Negative impact on morale of rest of team * Re…

Eh. Employers in the USA have very little incentive to worry about this, especially big employers.

Even if they manage to piss off an employee, it might take said employee a couple of months to find a new job (assuming they're in a field like programming where there are any jobs at all).

And the employee won't even start looking for a job after they've been unhappy for several months, because finding a new job is an exhausting, demoralizing timesink; it can be all but impossible to conduct an effective job search while handling other "real life" demands. Not to mention that it's "bad" to leave a job too soon.

And the employee can't just quit because their access to healthcare is dependent on having a full-time job with benefits. Individual market healthcare plans are all but unaffordable. Not to mention that it's "bad" to have a gap in your resume.

So even if the employee starts hating their job by month 2, if they aren't some kind of super-hot commodity in the job market, they won't leave until month 12 at the earliest. Heck, they might not ever leave at all.

Adjusted for the probability that the employee might leave in any given year and amortized over the lifteime of the employee at the company, the costs of making an employee unhappy are trivial compared to the value that can be extracted from them before they quit.

And that's all assuming that employees are somewhat non-fungible. For a job that doesn't require specific technical skills, employees are essentially fungible. This is kind of a good thing for society, because it means that there is a large number of educated, thoughtful, high-functioning people out there with good communication skills. But it's a bad thing if you are one of those people and you need to pay rent and go to the doctor.

People on HN (and in tech generally) seem to forget that they are tremendously fortunate to have any seller power at all in the labor market.

Re: Why COBOL Isn't the Problem

#38

Post by smnrchrds »

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…

It's state government. Everything is a cost centre.

Re: Why COBOL Isn't the Problem

#39

Post by marktangotango »

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.

Re: Why COBOL Isn't the Problem

#40

Post by pullmn »

Deukhoofd wrote: post #6

I agree to some degree that learning a new language is easy, but learning a new language and understanding its intricacies that could cause issues in a program takes a whole lot longer. It takes a whole lot less time for an experienced COBOL dev to understand a program than it takes for an experienced programmer who just learned COBOL to understand it in my experience.

Yes, I think that this article missed the point to some extent. Knowing C quite well and C++ not very well, learning the Java 'language' was quite easy. Learning the Java 'model'/'runtime' was much harder and ultimately more important.
Post reply on HN