Why COBOL Isn't the Problem
lucidchart.com
Why COBOL Isn't the Problem
1–10 of 59 posts
Re: Why COBOL Isn't the Problem
#2> Actually providing the programmers the time and money to make sure
In my experience management sidesteps that problem by insisting that you're an incompetent fool if you need time and money to accomplish anything.
Re: Why COBOL Isn't the Problem
#3> Actually providing the programmers the time and money to make sure In my experience management sidesteps that problem by insisting that you're an incompetent fool if you need time and money to accomplish anything.
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.
Re: Why COBOL Isn't the Problem
#4Also, the program written in COBOL often comes with an ecosystem that can be harder to port than the code itself. Record vs stream oriented filesystems, batch job subsystems, file transfers, block mode terminals, and so on.
Re: Why COBOL Isn't the Problem
#5> Actually providing the programmers the time and money to make sure In my experience management sidesteps that problem by insisting that you're an incompetent fool if you need time and money to accomplish anything.
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.
> 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.
Re: Why COBOL Isn't the Problem
#6I 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.
Re: Why COBOL Isn't the Problem
#7To COBOL's defence, the compiler generates very fast machine code, so COBOL is all right in my book id est screwing around with the intricacies of that language is okay since the end result is a fast, small program. Based on these two criteria, I conclude that it's well worth the effort on the programmer's part.
Re: Why COBOL Isn't the Problem
#8As I see it that this was a organizational culture failure where he tries to explain it with a technical debt problem.
I see the fingerprints of almost feudal organization structure the other aspects when I first read about the New Jerseys problem with COBOL.
Re: Why COBOL Isn't the Problem
#9My takeaway: if New Jersey had decided they could save money by just never changing the oil in all their state-owned vehicles they would have been in the same situation as they were when they chose to save money by not maintaining their state-owned software.
Re: Why COBOL Isn't the Problem
#10I 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.
I don't know almost anything about cobol, but from what I understand, there are more intricacies than language in cobol, so yes, it takes long to learn it.