Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Businesses The Almighty Buck

Cobol Job Market Heating Up 288

snydeq writes "Developers seeking job security in the years ahead could find an unlikely edge in Cobol. According to an InfoWorld report, demand for Cobol skills is surging, with salaries on the rise. More importantly, the short supply of offshore Cobol programmers and the fact that mainframes aren't going away anytime soon are spurring longevity for big-iron skills, with many companies looking to hire in-house Cobol pros to bridge mainframe Cobol apps to the rest of the enterprise. The report provides further evidence that Cobol may indeed be primed for a comeback, with new kinds of Cobol integration jobs emerging to prove old-guard skills are critical to some of the hottest areas of software development today."
This discussion has been archived. No new comments can be posted.

Cobol Job Market Heating Up

Comments Filter:
  • by truthsearch ( 249536 ) on Thursday October 23, 2008 @02:25PM (#25485205) Homepage Journal

    A company can spend a few million dollars rewriting and thoroughly testing a replacement system. Or they can spend less than 10% of that to have one Cobol developer keep the system up and running.

    Very often, the old systems have been working smoothly for many years. A rewrite will bring a monstrous amount of headaches and cost, especially for key systems like financial transactions.

  • by LWATCDR ( 28044 ) on Thursday October 23, 2008 @02:35PM (#25485349) Homepage Journal

    Because it works?
    A good programmer is a good programmer. They all cost about the same.
    Really if you have a system that works why pay to reinvent the wheel? The pay to retest it.

    So the answer is. Because it works.

  • by Ironsides ( 739422 ) on Thursday October 23, 2008 @02:36PM (#25485353) Homepage Journal
    How much do you trust your paycheck to get to you on time with a brand new piece of code vs. one that hasn't had any problems in 30 years?
  • by jjohnson ( 62583 ) on Thursday October 23, 2008 @02:36PM (#25485355) Homepage

    On an industry wide scale, it probably does cost more to keep paying COBOL programmers to maintain legacy systems. But at any individual company, the short-term cost of paying a high hourly rate to an aging COBOL coder to keep the wheels turning is much less than the cost of rebuilding the system that's run the company for forty years.

    Remember Schwarzenegger wanting to cut California state employee's salaries to minimum wage for the duration of a budget crisis? It was the state IT department that nixed that idea by pointing out that it would cost millions over the course of a year to execute that change. That's the situation in which many companies dependent upon COBOL find themselves. Pay someone $200 an hour to make minor changes, or face a years long rewrite costing millions (or a years long implementation of SAP costing tens of millions).

  • Is this a repeat? (Score:1, Insightful)

    by Anonymous Coward on Thursday October 23, 2008 @02:37PM (#25485371)

    Didn't I see this same headline 2 years ago? And 2 years before that? And another 2 years before that? And there was that big "post-y2k-bugs need cobol programmers even more!" 2 years before that ... and of course, the "Need for cobol programmers for pre-y2k" each of the 2 years before that ...

    Seriously, we get it. Every even year, someone is required to post an article stating that the need for cobol programmers is increasing.

    Can yah shut up about it now?

    The need for C, C++, Java, *.NET, and other language programmers is also increasing, and it so far outstrips the need for cobol programmers that they're statistically insignificant, and that includes factoring in any salary differences.

  • by AppyPappy ( 64817 ) on Thursday October 23, 2008 @02:45PM (#25485463)

    Especially when you are not really sure what the code does. If it works, you try not to mess with it. Many of these systems were written when memory was pricey and variable names cost something. It can be hard to figure out what they did when you are trying to analyze a variable called WC03-IDX that is used 62 times. COBOL may be "fat" but memory and processors are cheap now. I worked for a company that hired non-programmers to cut code and handle maintenance. It was all in COBOL. Nice, easy-to-read-at-2AM COBOL.

    But I still live in fear of CICS.

  • by DerekLyons ( 302214 ) <> on Thursday October 23, 2008 @02:45PM (#25485477) Homepage

    Why is Cobol still alive and in demand?

    Because there still exists in the world companies and people that have priorities other than "the latest l33t technology".

    Why can't we just port everything over to a newer language and be done with it?

    Assuming the hardware can run the newer language of course... But you still have to face the same basic problem, in a few years your l33t "newer language" will no longer be l33t or newer - it's be the stodgy old stuff that only crusty old farts program on. What then? Go through the same exercise every five to ten years?
    That sounds more like a recipe for keeping programmers employed, regardless of value, than it does for keeping a system stable and operational. (Which a large part of why IT is often viewed with such suspicion in many quarters - because the constant rewrite/upgrade cycle that keeps the IT departments e-penis turgid rarely seems to provide much of a ROI.)

    Doesn't it cost more to keep paying these rare programmers than to just update/convert/replace the systems?

    A handful of (COBOL) programmers costs the company just a couple of million dollars a year for a stable functional system. A stable of ($l33t_language) programmers costs about the same, plus the potential costs of hardware changes, plus the potential for months of disruption or loss of data...

  • by theaveng ( 1243528 ) on Thursday October 23, 2008 @02:53PM (#25485617)

    $120 an hour?!?!? If I can learn the mess that is 8502 assembly, I can surely learn the Cobol mess too.

    (runs off to find tutorial)

  • by Anonymous Coward on Thursday October 23, 2008 @03:16PM (#25486031)

    "The thing is - most mainframe custoemrs kept up with hardware changes. Old code written on a 370 will still run (as binary) on modern mainframe hardware, which will, of course, run circles around the usual unix box and floss it's teeth with disemboweled intestines of web designers."

    Sorry had to change it. I could see using their pointy heads like a dental pick, but not floss.

  • by Anonymous Coward on Thursday October 23, 2008 @03:34PM (#25486345)

    Everyone who wonders why COBOL still exists should recall the oft repeated advice to use the language that is best suited to solving the problem. Then look up the meaning of the acronym. COBOL is the acronym for COmmon Business-Oriented Language. COBOL still exists because it was designed to implement business applications and most businesses, wonder of wonders, rely on business applications.

    That and "if it works don't break it."

  • by daemonenwind ( 178848 ) on Thursday October 23, 2008 @04:12PM (#25487155)

    More as opposed to what?

    Only large organizations use mainframes, so it helps to look at that model.

    Large companies generally bin out salaries for most professionals. Developers are no exception.

    So you'll get tossed into an income bin with people of similar relative experience. Having a scarce skill will push your income towards the top of that bin. So if the range for "Developer 1" is $52,000 - $75,000, you'll be closer to the upper end. If you're comfortable being a contract consultant under your own name, you'll probably be able to get a decent hourly, whatever your local market goes for.

    But if you're expecting this to be the second coming of the HTML millionaires, you're probably going to be disappointed.
    The most likely outcome is that retired baby boomers will come out of retirement, as part-timers or as occasional consultants, as was done for Y2K.

    What coding COBOL CAN do for you is grant you a level of job security you otherwise might not know.
    Many flavors of the week have come and gone during the COBOL run, and many more will yet. The systems written in COBOL were put on the mainframe because they are fault-intolerant heart and soul of the businesses they support.

    And if you support those systems, so are you.

  • by neiljt ( 238527 ) on Thursday October 23, 2008 @04:17PM (#25487245)
    Variables are only global within the program unit. The equivalent of a C function call, e.g. "CALL MODULE USING PARMS" allows local variable scope within MODULE.
  • by sohp ( 22984 ) <snewton&io,com> on Thursday October 23, 2008 @04:17PM (#25487253) Homepage

    Cheaper in the short term, and the long term costs are difficult or impossible to see. As anyone who has been paying attention to economic news lately knows, it's all about the short term, and damned be the long term.

    There's no good economic or technical reason to keep these systems around -- the fact that they are still being used and patched is a reflection of office politics and managerial failures.

  • by VeNoM0619 ( 1058216 ) on Thursday October 23, 2008 @04:48PM (#25487991)
    Thanks for the assumptions. No, most COBOL programs are NOT accounts payable, and DONT run for just 8 minutes, and DONT handle just 100k of memory.

    I have seen plenty of COBOL code (one program containing over 10,000 lines), now try reading through it and understanding the scope of each variable, when the working storage itself takes up 2,000 lines of code (at least 1,000 variables, ALL global, ALL being used 'randomly' throughout the entire program). These are the programs that no one touches, because of fear that the system is just too complex. This is why these things are not rewritten for the newest/popular programming language.

    While a program like this is more efficient (because you don't have to allocate/free memory at all during execution) it is very hard to understand. This is one of the tradeoffs between newer languages as well. Now, some may want to argue that allocate/free times are 'negligible', but to some companies that process 24/7, every bit literally counts. I'm not for COBOL or trying to promote it though, I wouldn't mind a more easily readable language, but EVERY language has it's problems.
  • by illumin8 ( 148082 ) on Thursday October 23, 2008 @06:45PM (#25490079) Journal

    Big Iron is here to stay.

    Awesome. You, sir, are a true legend, a veritable man among men, an uber-hacker.

    If you aren't part of the solution, there is good money to be made prolonging the problem

    Somehow, your sig feels fitting for this entire story.

  • Job market (Score:2, Insightful)

    by jwsmith00 ( 262885 ) on Friday October 24, 2008 @07:05AM (#25495785)

    There are some key differences between the COBOL and Java job market:

    (1) Interviewer: Do you know COBOL?
    You: Yes
    Interviewer: Ok, you're hired.

    (2) Interviewer: Do you know Java 1.5, Spring 2.0 and iBATIS?
    You: Well, I don't know iBATIS but I know Hibernate and SQL. And I know Spring 1.2.
    Interviewer: Well, we're looking for someone well versed in Hiberate and Spring 2. You don't get quite have the skillset, you don't get the job, have a nice day.

    Where I work, COBOL is written once and run for a long time. The Java environments are always changing, and code is often re-written is different frameworks every few years. HR staff are full of buzzwords. And in the COBOL environment, there's only a few buzzwords: DB2, COBOL, JCL, IMS DB/DC and they haven't changed in decades.

These screamingly hilarious gogs ensure owners of X Ray Gogs to be the life of any party. -- X-Ray Gogs Instructions