Funky idea:
Serverless is Mainframe(COBOL) without transactions
Why COBOL Isn't the Problem
11–20 of 59 posts
Re: Why COBOL Isn't the Problem
#12I 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.
Also hiring people for a language that nobody knows anymore will be much tougher.
Re: Why COBOL Isn't the Problem
#13As 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.
He's trying to explain that the reason you end up with so much technical debt in the first place (after explaining to a layperson what that is) is /because/ of organizational cultural failures.
Re: Why COBOL Isn't the Problem
#14Earlier 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.
> 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.
Re: Why COBOL Isn't the Problem
#15I still wonder what would happen if IBM sold a IBM i for $499 only licensed for developers. It's not like the thing really needs high end specs. I wonder how many programmers would go for it on a fluke. Would be good for schools too.
Re: Why COBOL Isn't the Problem
#16> 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.
> 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
* Rest of team needing to support work
* Recruiters fees
* Time spent recruiting
* Customer frustration
* Replacing them with someone worse
* Extra mistakes
Re: Why COBOL Isn't the Problem
#17There 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 programmers were often meant to be "less" than real programmers. More like junior accountants automating boring procedures, than C wizards. Wizards would not touch COBOL code with a stick. This often shows.
This said, the kind of things you could do on a IBM mainframe in the '70s (virtualization, data safety and efficiency, disaster recovery, even uptime) still run rings around the 90-core boxes with Linux that are in your datacenter racks.
Re: Why COBOL Isn't the Problem
#18As 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.
He's trying to explain that the reason you end up with so much technical debt in the first place (after explaining to a layperson what that is) is /because/ of organizational cultural failures.
There is a difference between accruing technical debt on a legacy system is one thing, that is something that almost never can avoid. The other is to panic hire someone when the proverbial shit hits the fan is another story. That is the biggest dysfunction here that someone realized they didn't have the competence to maintain their COBOL code in house and it was their responsibility, but only after it stopped working.
Re: Why COBOL Isn't the Problem
#19To 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.
it's well worth the effort on the programmer's part
It's worth it if you have all the supporting pieces in place. For example if your OS provides record-oriented I/O and your hardware platform provides dedicated processors for accelerating I/O, then you can write a very small, efficient program to, say, calculate today's interest rate and apply it to millions of accounts. But if you don't have those things then you need to write a lot more code and/or have another program (e.g. a database server) to try and emulate them in software, and it will be slower because it has the overhead of calling between components rather than being tightly integrated.
Re: Why COBOL Isn't the Problem
#20Are the cobol devs from the past the equivalent of the modern day vbs and excel script persons?