Slashdot Mirror
Should Banks Let Ancient Programming Language COBOL Die? (thenextweb.com)
COBOL is a programming language invented by Hopper from 1959 to 1961, and while it is several decades old, it's still largely used by the financial sector, major corporations and part of the federal government. Mar Masson Maack from The Next Web interviews Daniel Doderlein, CEO of Auka, who explains why banks don't have to actively kill COBOL and how they can modernize and "minimize the new platforms' connections to the old systems so that COBOL can be switched out in a safe and cheap manner." From the report: According to [Doderlein], COBOL-based systems still function properly but they're faced with a more human problem: "This extremely critical part of the economic infrastructure of the planet is run on a very old piece of technology -- which in itself is fine -- if it weren't for the fact that the people servicing that technology are a dying race." And Doderlein literally means dying. Despite the fact that three trillion dollars run through COBOL systems every single day they are mostly maintained by retired programming veterans. There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language. Doderlein says that banks have three options when it comes to deciding how to deal with this emerging crisis. First off, they can simply ignore the problem and hope for the best. Software written in COBOL is still good for some functions, but ignoring the problem won't fix how impractical it is for making new consumer-centric products. Option number two is replacing everything, creating completely new core banking platforms written in more recent programming languages. The downside is that it can cost hundreds of millions and it's highly risky changing the entire system all at once. The third option, however, is the cheapest and probably easiest. Instead of trying to completely revamp the entire system, Doderlein suggests that banks take a closer look at the current consumer problems. Basically, Doderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems.
Having spent quite a bit of time over the last two years to re-implement in Java a system developed by the government in COBOL, I can tell you that COBOL will probably never die. For example, keeping precise, penny-perfect calculations of dollar amounts in Java is actually quite a pain. This is especially true when the calculations involve dozens of hundreds of steps. My solution in Java has been based around BigDecimal, which makes the code very difficult to read. Aside from that, I have spent the vast majority of the time writing very extensive tests and chasing down really small numeric discrepancies. Guess what, if you decide to replace a COBOL system that does any appreciable amount of math, you would get to do the same thing. Plus, you will never be sure that you found all the bugs.
The project actually considered the possibility of licensing a commercial Cobol runtime for PC-based platforms (e.g., Windows, Linux, etc.), but that was not feasible for several reasons.
COBOL is still remarkably good at quite a few things and leaves out lots of the bells and whistles that tend to become distractions in the hands of undisciplined programmers. My only complaint about COBOL (especially old COBOL) is that the control flow is a real pain. Aside from that, it is definitely a workhorse of a language. No need to go killing it off yet.
2 years ago in one of the banking centers in Denmark 12 new IT-candidate were educated in ... COBOL, CICS, mainframes, etc. The older generation were anxious about how the younglings adapt, but it appears it turned out well. They were excited about the robustness and scalability of the mainframes, not so much about COBOL, but could see it didn't make business sense to rewrite old software. New software is being developed in more modern programming languages.
source (Danish only): https://www.version2.dk/artike...
Indeed. If there is a market for COBOL programmers (and it's clear there is), then the obvious solution is for unis and colleges to spit out more COBOL-literate CS graduates. Honestly, if I was ten years younger, I'd probably delve into it myself. It is, after all, just a programming language, and hardly on the same level of trying to learn Sanskrit.
As long as you have a real fall-back so your career doesn't dead end. What can easily happen is that you do X then more of X because it's the only place you get a salary/career development until you've done X so long nobody will really hire you for anything else. I see this with for example some SAP consultants, essentially SAP customers want to hire you for your SAP experience and the rest of the world doesn't care that you have a general IT degree 5 or 10 years ago because your experience is all SAP-specific and they don't run SAP.
Now they're probably safe since that ERP is burrowed so deep into many companies they'll never get out, but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position. That is if they'll even hire you or if they'd rather have a recent college graduate. Or you might have to relocate to find one of those increasingly rare positions that actually value your COBOL experience, which of course only makes it harder at the next crossroads.
If you write cell phone apps as a hobby and can show them a portfolio or something, maybe you'll get away with it. No, you're not a dinosaur who only knows an outdated language and best practices from 50 years ago. Or some other way to be able to transition away from that COBOL career more smoothly. Some of my older colleagues noted that the parking inspector at work used to be COBOL programmer some 20 years ago, they updated their skillset and apparently he didn't.
Live today, because you never know what tomorrow brings
COBOL is simple. It is also relatively limited. This makes it easier to track, troubleshoot, and maintain. With Banks, accountability is more important than functionality.
Said the person with very little knowledge of modern COBOL environments !
I'll grant that COBOL is not like PL/I, where 80% of the programmers know = 20% of the language.
However, COBOL has one of the richest I/O layers (ok, on par with PL/I) around.
Caveat Emptor - I intensely dislike the language (to damned verbose), but it and PL/I do pay fund my paycheck (just call me 'Dinosour Bob'). ... And Databases where not yet relational !
But the COBOL I learned was circa 1970s, when even COMPUTE was frowned upon (in school)
Modern COBOL has OO patterns, JNI integration, XML/JSON tooling, ... All to deal with the option of: ...)
* Keep the business logic in COBOL
* Provide the ability to work with newer toolchains (Java, XML, JSON,
So there is interoperability betwixt the green-screen and non-green-screen luser.
I went to community college and we had an Associate's track in, basically, mainframe computing. AS/400, JCL, COBOL because we had several local firms that still maintained and ran mainframes (and last I checked, still do. I believe one tried to move to commodity hardware and rewriting the whole stack in Java, but I don't know if they finished that transition).
The problem with "just picking up COBOL" isn't necessarily the language, it's the whole system it's deployed on. There's no CLI that a Linux user would readily recognize (I found it easier to think of it like a BBS), the whole Jobs system is utterly alien to someone used to VAX/UNIX, etc etc. My local college also did a lot of that, but in the MIS department. The EE department started everyone out on VAX/VMS and Pascal, the CS department on C and qedit. :D They moved to Visual Studio not long after, though.
Even if students coming out of a course should grok code in general, that doesn't mean they have discipline-specific skills in COBOL necessary to allow them to deal with this kind of code. Some of that stuff is learned over decades.
It's entirely the bank's fault for not taking on young employees and teaching them these new skills, and putting them with the veteran programmers and guaranteeing their jobs for life, with good pay and conditions. They have no one else to blame.
Had they done this, it wouldn't be a problem. COBOL would just be the language that banks use - nothing else. Banks seem to feel it's the universities responsibility to churn out skills that they might want some day, but without paying either the universities or the graduates ( through employment ) for their services.
They still have time for this - all they need to do is pay enormous amounts to programmers willing to sit with and replace aging veterans. Good luck to them. I hope the banks choke on this.
When I studied, we were forced to learn COBOL for precisely this reason. No one was ever hired, or taken on, or otherwise employed out of it - It was just one of those "Industry want this, so we're teaching this" situations, but the truth is that industry only ever want experienced programmers, but they want them to gain that experience somewhere else.
When we see COBOL programmers paid 1 million per year, like high-flying executives, we'll know they finally realized their value. In the mean time, maybe a few more executives should be prosecuted when they have losses due to COBOL bugs and failures, for running systems they refused to maintain, with foreseeable outcomes.
I remember this coming came up during the Y2K flap. COBOL programmers are dying out because companies have decided, for whatever reason, that they aren't willing to pay them much. A quick Google search--I don't know how reliable--shows me:
COBOL Sr. Software Engineer / Developer / Programmer $88,049
Java Sr. Software Engineer / Developer / Programmer $103,239
But that understates the difference because the various job titles shown for COBOL positions are predominantly lower-sounding and lower-paid positions.
As several have said, COBOL isn't hard to learn--I don't know it but I crammed it once for a test. Like all languages it takes a while to get good at it, but it's not specially difficult, nor is it specially bad.
The best strategy would be to render unto COBOL what is COBOL's--keep good legacy systems in COBOL--and pay enough to give people a reason to learn the language.
"How to Do Nothing," kids activities, back in print!
Exactly, if there's a demand for it, it'll be fulfilled. The article reads like something written by some recent CS grad, lets throw out this horribly uncool, unhip code that nevertheless can handle three trillion dollars of transactions a day and has been going for forty years and replace it with something that some Indian subcontractors slapped together using Ruby and MongoDB.
In a past life I worked for a bank. They decided to replace their existing Cobol on IBM big iron with Java on... something that wasn't big iron. After several years work and tens of millions of dollars spent and even more than that lost due to problems with the new, modern replacement systems, they threw in the towel and made their modern system screen-scraped 3270s because that shit just works, and keeps on working. It's now all Windows-based at the front end, but everything in the backend is still Cobol on mainframes.
At my college the low level CS classes were taught using Scheme. The idea was to use a language that nobody would ever in their right mind use in the "real world" to teach basic concepts like recursion without the student getting bogged down by implementation details specific to a language. Higher level classes were taught in Java so that we would have experience with a 'real' language. Also, there are some concepts that are nicer to work with in a powerful modern language, rather than shoehorning them in to an obsolete language not designed to support them.
Holy shit dude. I'm a vet C++ programmer and the last three years mobile developer for warehousing company. However about a year before my current job, I worked in an exclusive AS400 shop. RPGLE, COBOL, CL, you name, it was still using the stuff from back in the day.
The system was incredibly fragile and had insanely complicated builds with the labyrinth of binding directories, dependencies, the constant service program signature violations. Customers demanded new functionality and the system just had trouble keeping up. Old programmers would code crap like RPG still lacked arrays with abusing subfiles. They'd swear by using numeric indicators versus the new fancy types. Yeah, because IN73 being on tells me that I totally need to refresh the data on the screen. Eventually the company fired all of the RPG/COBOL programmers because they could never keep up with demand. They were short order replaced by an off the shelf solution and any new work was contacted out. I stayed on a few months more because I understood EDI and they needed someone to get that all setup on the new solution. Oh and it was Java based.
Point though, you sound exactly like those old guys. OO over complicates crap and you don't need all that fancy stuff, blah blah blah. I work and coded DDS, SQL, RPG, and COBOL with those people for five years and I knew their mentality was just setting them up for obsolescence.
The tech industry is brutal man and you've got to be a person keenly adept to rapidly adapt or you'll find yourself quickly no longer employed and lacking serious skills to find your next job. Two, besides myself, out of our group of nine found another job. Those two for jobs doing AS400 maintenance, took a pay cut for it, and RPGLE programmer with the State Government, smaller hit to the paycheck than the first guy. The rest of the group have nothing but their retirement savings to dip into. We all lost touch over the years but last I heard two or three more for jobs finally but had to eat the cost of moving elsewhere.
Seriously, the only thing that kept me above water was that I had skills in C++ and Java. And since then I've picked up containers with Linux and node.js plus Python and some big data (Hadoop and shit) just to what I assume is stay current.
That thinking of yours isn't a good kind in this industry. But I get it, when I worked with the AS400 folk, I had just turned 30 and so I was seen as the young whipper snapper etc. I had just left my last job of several years doing C++ and every gray beard (literally) there thought I was there to "think outside the box" and "shift paradigms" and really I was just there to mostly get a paycheck. Learning RPGLE and COBOL was fun but man those old guys they scoffed at any suggestion to get off a green screen or to make their monolith more modular. They would literally say, "stupid hipster just trying to make everything harder than it needs to be." And let me tell you, I didn't dress like a hipster.
Anyway, I know, way more memory lane than anyone asked for, but seriously, those guys' thinking ultimately led to their firing. I've worked in a few development teams but not a lot so can't say with a lot of experience, but my gut tells me that had they been just a wee more open to change and newer technologies, they might still be working at that place.
Fretting that banks may have to pay to train software engineers to learn the tongue of their industry instead of getting to pay dirt cheap rates to retirees is very far from tugging at my heart strings.
There are banks and banks. I work at a hundred-year old bank where most of the COBOL programmers are between 30 and 45. The older ones have graduated to team lead, plain management, auditing, cost control, or other (presumably better-paying) posts. There are lots of people recruited out of school to work on COBOL (and Hadoop, and CICS, and Kafka, and OPC/TWS, and NodeJS, and if you only know one in two then you're not cross-platform).
This is good HR. There are people in HR whose job it is to plan out career paths and make sure on one hand that people don't get stuck with only outdated skills, and on the other hand that the bank doesn't get stuck with not enough people competent in a given skillset. If other banks don't have good HR, then I'm sorry for them but it's not my problem.
Yearly pay is not that great, but I have job security, I can go to the beach after work, and if you factor in that I have 56 weekdays off in a year it gets better... and bad pay is probably a consequence of having competent HR too.
but for something like COBOL you could end up doing it for some years and then the legacy system is shut down and nobody wants to give you anything but a junior non-COBOL position.
You think that a systems migration won't need your legacy skills? You think that you won't pick up the skills for the new system during the migration?
Here's a more likely scenario: you do COBOL for 5 years and learn the entire problem domain that the COBOL system services. When the migration occurs with Java your knowledge will be indispensable, and you'll no doubt learn Java in the two years the migration takes to complete. At the end of the migration, you are still the expert in the problem and have new Java skills to apply your expertise.
It's exceptionally unlikely that the migration from COBOL will be so fast that you won't be able to learn the new implementation technology.
I'm a minority race. Save your vitriol for white people.