Slashdot Mirror
Why COBOL Could Come Back
snydeq writes "Sure 'legacy systems archaeologist' ranks as one of the 7 dirtiest jobs in IT, but COBOL skills might see a scant revival in the wake of California's high-profile pay-cut debacle. After all, as Fatal Exception's Neil McAllister points out, new code may in fact be more expensive than old code. According to an IDC survey, code complexity is on the rise. And it's not the applications that are growing more complex, but the technologies themselves. 'Multicore processing, SOA, and Web 2.0 all contribute to rising software development costs,' which include $5 million to $22 million spent on fixing defects per company per year. Do the math, and California's proposed $177 million nine-year modernization project cost will double, McAllister writes. Perhaps numbers like those won't deter modernization efforts, but the estimated 90,000 coders still versed in COBOL may find themselves in high demand teaching new dogs old tricks."
I think many people missed the point of the California problem. It wasn't limited to lowering everyone's earnings to minimum wage. The main problem was that after the budget was approved, everyone's wages needed to be adjusted again AND those people need to have back wages paid for the period that they we being paid less. That's a complex problem that most programs, even modern ones, probably are not designed to consider.
Where I live, COBOL is used everywhere. I'm 33 years old and I use it on a daily basis and have been since I graduated from college 10 years ago.
.NET, and compared to them, working on COBOL is like taking a day off. It's top-down design makes it easy to read and follow, and as long as you aren't dealing with "go to" code, it's no harder than anything else out there.
Companies like Wal Mart, ACXIOM, and large transportation companies such as JB Hunt, ABF, USA Truck, Wingfoot Commercial Tire, and Data-Tronics use it day-in and day-out.
However, unlike the COBOL I always read about here on Slashdot, the code we work with is standardized, modularized, and backed with a relational database (IBM DB2).
I also happen to work in more modern languages (compared to COBOL) such as PHP, ASP, and
Don't disregard a language simply because it's old, or because you don't have a fancy IDE to rely upon. Compared to some of the messy AJAX implementations I've seen, I'd take COBOL any day.
Coming from someone who is currently supporting a legacy COBOL system, you're right on target.
COBOL is shit. Most legacy COBOL code is not designed with anything like what we'd consider "best practices" today. The language itself is unfriendly, and doesn't lend itself to the modern world.
What it does have is inertia. It works, right? Why replace it? It's the product of decades of business evolution, do you think you can replace that overnight? New code will never be as good.
Basically, they're comfortable with their crusty old bugs, and they don't want to deal with scary new bugs.
In my environment we've basically thrown this whole interface built on Oracle and Java on TOP of the old COBOL MPE/ix system. Placates the conservative financial types, while providing some modern functionality.
Still there are all kinds of problems with the old systems. You can end up with some really scary problems with old code, because it doesn't recover from failure like you'd expect modern code to. A java billing application running on a modern transactional database...If it crashes, you can just run it again. A COBOL app on a legacy database? That just ruined your day.
I would hope that the response to the situation would be to finally migrate your systems, not to accrete more levels of unsupportable crap by dragging COBOL programmers out of retirement, or forcing existing programmers into that outdated mold. I know the money types though; they are perfectly capable of trying to stick with the outdated method simply because it's in their comfort zone.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Yup, no doubt the people that implemented this system were complete idiots, unable to come up a system that was 'well designed'. Oh wait, I wonder what 'good design' was when this was written. Maybe it included things such as 'being able to run in a machine with 16MB virtual address space, with 1MB real memory installed'.
As for security, you're probably also right there. It seems just about every week I read a report of some COBOL-based payroll system being hacked (which you would expect, since there are probably thousands of such installations). Oh wait, I never read that.
It seems to me you are quick to criticize, without even a basic understanding of the requirements for this change. It is NOT some simple 'raise minimum wage'. It is 'temporarily lower ALL employees wages (hourly and salaried) to minimum wage'. When the budget is passed, put the wages back where they were and issue back pay. Don't forget about little details like deductions for taxes, insurance, retirement, etc. How do you calculate the withholding rate for income tax? What do you do when someones deductions exceed their pay? When the pay is restored, what do you do about people that have left, retired, or died in the meantime?
I think that the timeframe they give is not all that unreasonable, considering all that must be done. It will take a substantial amount of time just to come up with complete requirements. Then the coding must be done. Since this is a financial application I am sure there is much testing, and probably some fairly stringent auditing that must also occur.
Like was mentioned in a previous reply, it's not JUST learning COBOL, there is also other stuff like CICS, that you have to know as well.
But you take something else like C. I can get gcc, and start writing code. Same thing if I want to do some web 2.0 project. It's almost trivial to get a LAMP setup up and running.
There's nothing that can simulate a working z/OS environment. There's no compilers to download. There's an emulator out there called Hercules for various IBM mainframes, but you can't get the OS to run on top of it. It's near impossible to go grab "COBOL for Dummies", and start firing up code. COBOL is also rarely taught in university anymore. So the only place you COULD get some exposure to the system, you aren't going to get it. Even if you COULD download the OS, setting it up is very nontrivial. And it's NOTHING like you've seen before.
And these systems aren't just 100% COBOL either. There's a host of mainframe type things like Natural for an ADABAS Database that you're NEVER have experience doing unless you already have a job doing it. You got to the point to where you wrote that program in COBOL, now do you know the JCL to set it up to run? Ok it ran, know what a SOC-7 error is? BTW, it's an uninitialized numeric to save you from typing it into Google.
All these things mean the vast majority of people out there now just don't have ANY experience in dealing with these things. It's hard enough to find people that can step into a team to support a major project. Add in those legacy requirements, and it's probably nil. Anyone qualified to do it, is probably 3 years from retirement from where they are at, and would probably have to offer 7 figures a year to make it worth their while to screw up their retirement options.