The problem might not be COBOL
adhoc.team
adhoc.team
So you get old fine working do the job systems, then you get what I call bolt-ons to those systems, web front-end and the like that all distill the input into a format the old working system can take in. Which is fine, but the data limits of the back-end really do start to stand out more and more then and seen many a case of a front-end allowing more input only for it to get blindly truncated before it is fed into the backend. Things like that can and do create interesting issues. Though as true today as it was back when COBOL was born - garbage in garbage out.
Depending on how complicated the business logic rules encoded in the old backend are, could this be more efficient than modifying the old backend?
But it all boils down to how the old system stores data, and some will enable you to hold multiple records and for example a comments field. May have the last character closed of from input as it is a continuation marker that means there is another record and they are joined, as you say two records. Changes like that will entail changes to the backend, though the impact can be more manageable than alternatives.
Then you can use replication or data warehousing and from that, lots of reports and other aspects that would hammer the backend become much more pleasant.
Crux is the limitations, things like names, so entwined into a system that it does not lend itself to the two records solution. So you use another solution.
You mention business rules and that is very much key and having somebody who knows the business logic is way more valuable to understanding the a system than knowing the language it is written in. So as an aside, if I had to employ somebody to work on an old legacy system, I'd take the person who knew or showed a grasp of the business logic and how that works over somebody who knew COBOL. As it is easier to teach COBOL than an entire business. COBOL has many books and resources, a business tends not to have such clear cut documentation.
The big issue with COBOL is developer availability. I can easily find a lot of C programmers to fix and extend my complicated C code base. I can easily find a lot of programmers familiar with SQL to help me fix and improve or change my queries. Finding COBOL programmers is a much harder task and C and SQL programmers.
And it is not about the age of the programming language. My guess is that it would be harder finding PL/1 or Algol 60 programmers even though both of those languages are newer than COBOL.
It might be difficult to find a substantial number of people who actually want to be trained in COBOL.
I myself can handle a lot of drudgery for $350k a year.
Good developers - those who like what they do - won't touch it with a stick. People do OCaml, Haskell, Clojure in their spare time and C# and Java at work - but nobody codes COBOL in their spare time. People code in Assembly, sometimes in hand-assembled hexadecimal format, but not COBOL.
It's a job, usually a boring one.
The language is just at tool; being fixated on OCaml or Haskell or whatnot seems like mistaking a tool for a goal.
I'd love the opportunity to work one of these applications. It's different from anything I've done before and all other things being equal is certainly seems more interesting than working on the 6162th ride hailing app or some ad-tech meaningless nonsense.
It also just so happens to be written in COBOL.
https://blog.carlmjohnson.net/post/2017/what-kind-of-program...
THAT is true of any language, the fact that COBOL has divisions does make it a bit easier. But you can also do very structored code in COBOL and code without using the GOTO verb. However many systems and code born the scars of the time. Fast code really did make a difference and was measurable in cost a lot more upon an expensive mainframe and when your processing near on a million records, very noticable in costs. So GOTO got used a lot, as coding for exception handling using structured programming like JSP (Jackson Structured Programming - the thing in the COBOL days) whilst doable, wasn't the fastest code and equally, not that readable if you didn't know the methodology behind JSP.
But over time you don't see the language, you see it from a data perspective and with that, code however laid out becomes easier to manage and by that, anybody else's code will look a bit yuk to you. Indeed it is rare to work on somebody else's code and come away with a warm fuzzy glow.
MARK IV is the oldest language in use that I know of that I have personally had contact with, and I've had contact with it recently. I would say that the issue isn't just finding Cobol programmers, but a mix of mainframe specific languages and technologies no longer in wide use outside of mainframes' data warehouse solutions, such as DB2 and VSAM.
The main problem with Cobol, REXX, JCL and MARK IV is that the solutions/problems encountered cannot just be google'd through stackoverflow or some online forum. Institutional knowledge from 30 year experienced self-starters or solution specific candidates with 30 years of experience in a piece of the project needing assistance who is willing to be a self-starter for gaining experience enough in the other technologies the mainframe uses.
On top of that they tend to be stodgy old corporate companies that developers hate, where you have to wear a suit to work and being seated by 9AM is more important than doing your job well. Then there's the fact that it could be career suicide to spend so long on tech that fewer and fewer companies are using. And you'll need an exit plan because it's used at become companies that do regular mass layoffs, they've probably fired more cobol programmers than they'll ever need. They should be paying a hefty premium to get people.
The language itself and surrounding systems can't be any worse than the standard enterprise XML DSL rubbish can it?
That I can attest happens, less so today but then such places lost most of their talent as those that could and able to move on did and those that didn't, well they would of been close to retiring and with that. Hence technical debt increases. But it's not just knowing the COBOL, it's not just knowing that business logic, but how the two go together - THAT level of knowledge was always undervalued in many institutions alas.
Perhaps some popular articles dismissed COBOL for its age. No programmer worth their salt would do so.
(I can't say whether or not COBOL deserves its reputation, and given how many reliable systems are written in COBOL I doubt it is fair to blame it for the failures of this website.)
The one really crazy COBOLism is "Alter":
https://www.ibm.com/support/knowledgecenter/en/SS6SG3_4.2.0/...
But all languages have parts which are not recommended to use.. just think of PHP.
There is an important word left out here. It wasn’t designed to meet the needs of people who currently need it.
Usually in a government agency is a layer of VB, J2EE from circa 2003, powerbuilder or some other array of old junk that is responsible for some business processes and is a make work program for hundreds of developers. That is the problem.
Whatever CIO is whining to the governor about COBOL need to be gone, now, and New Jersey needs to find somebody who can get the stuff around the COBOL reengineered and implemented quickly. Then start hacking the COBOL bits apart.
If you worked the same job for 5 years and got laid off, it’s closer to 30 questions. If you were laid off from a job after three months, worked at the post office in the last 3 years, got discharged from the national Guard with a service disability, it’s closer to 130 questions.
UI/UX is important because the business rules get complex and you can’t throw a random call center person at it — they need to know wtf they are talking about. You never have enough of those people. Making it a fully online transaction means someone needs to fully understand the business rules — which is harder than it sounds because new things get added often, and the old mainframes generally don’t get reengineered.
Also, when you say demand spike, in 2020, that means when all is said and done more UI applications than have been seen in the last 10 years, in a 60 day period.
The system wasn't built to handle modern workloads, that might be part of why people decry it being ancient.
Despite starting out talking about architecture, which would be a difficult problem to tackle when having to interface with systems built around abstractions and conventions of a couple different eras back, more than half the article veers into the relatively easier task of user-centric UI design that his company can bill for.
I mean, that'd be great too, but the article is bait and switch.
This has the feel of a corollary to Fred Brook’s The Mythical Man-Month; The Mythical Effective New Man After Many Inactive Months.
Negotiation your salary I guess is something learned and those who work at this company are fairly new in their careers(i think). Personally, I am not, so and again I applaud this company's mission of equality and pay parity. Yet for someone seasoned it led to find other places to work.. places where negotiating ones worth is allowed.
Also this poor explainer video that conflates several unrelated design decisions with limitations of COBOL: https://youtu.be/Ox_Wm6XQnxI
COBOL is a compiled language, so once compiled into machine language it doesn't matter as long as it runs.
I would be looking more at what hardware its on which is probably some Big Iron running system/360 that has a 2 week turnaround to add some extra memory. The code probably runs just fine, it's the hardware support cost and turnaround time that will be the constraint.