Forgot your password?
Programming Businesses Technology IT

Why COBOL Could Come Back 405

Posted by timothy
from the cost-of-doing-common-business dept.
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."
This discussion has been archived. No new comments can be posted.

Why COBOL Could Come Back

Comments Filter:
  • No Thanks (Score:5, Interesting)

    by Black-Man (198831) on Thursday August 07, 2008 @01:53PM (#24512781)

    I learned COBOL in college 20 years ago. I hated it and immediately knew COBOL, TSO, JCL, CICS was not for me. The user was shielded from the complexities of the system, whereas Unix and 'C'... everything was there to learn and discover. No 2-inch IBM manuals to sift through.

    Now I work at a place w/ the dinosaur and DB2/COBOL on the backend and I am forced to fix the crap COBOL code written by folks who are long retired. And it sucks... big time. And why these 50-something COBOL programmers think they are hot stuff is beyond me. COBOL is EASY compared to C/C++ or even Java/C#.

    The sooner the dinosaur is extinct... the better.

  • by loose electron (699583) on Thursday August 07, 2008 @01:58PM (#24512857) Homepage

    Does this make sense? As a HW person, I dont have a clue, but I would be curious to know what the conventional wisdom is here. Should this stuff be used in an obsolete language, using code constructs that were dictated by HW limitations (Y2K and 2 digit nonsnense) OR Should this be done in something that is HW independent (Java - if I can show my ignorance here) or something like C++?

    Teach me here folks!

  • Re:I don't get it (Score:1, Interesting)

    by Anonymous Coward on Thursday August 07, 2008 @02:07PM (#24513019)
    I used to do programming/support software written in a 60s era language. It was a step up from COBOL (One of the companies products was written in COBOL, and it sucked), but it wasn't modern. I suspect less than half of my coworkers had a CS degree, and I didn't consider any of them hardcore CS types. In fact, over half were women. Thing is, it's dull and boring business logic. There are probably a few hundred thousand bored housewives with the aptitude to learn and do COBOL programming. Hell, even CmdrTaco could probably do it... with a spellchecking IDE.
  • KISS (Score:4, Interesting)

    by Archangel Michael (180766) on Thursday August 07, 2008 @02:09PM (#24513069) Journal

    Keep IT Simple Stupid.

    No, not it, IT.

    Keep Info Technology Simple. We tend to want to add in all the bells and whistles we "want" but don't "need" because we can.

    When I build a system from scratch, it is fast, clean efficient. It has everything one of the user "needs" to do their job. It is fast, efficient and clean. And it doesn't have problems if they keep it that way.

    But they start adding in all the add-ons, upgrades, multiple versions of the same basic tools. Google, Yahoo, Myspace, Coupon cutter, Weatherbug, Ding (SW Airlines) etc ....

    Then they start to complain about how "slow" and "Buggy" the computer is. All those bells and whistles do nothing but distract the user from doing what he OUGHT to be doing.

    I see this within applications as well too. Feature creep is a real problem, as is trying to over simplify the front end, at the expense of the back end.

    Take a look at the comparison of Vista and XP, there is NOTHING in Vista that is really "needed", but it is a bloated mess when compared to XP. why?

    They don't want to KISS, they want "fancy", and fancy breaks, and is more expensive to fix when it does.

  • Re:I don't get it (Score:2, Interesting)

    by morgan_greywolf (835522) on Thursday August 07, 2008 @02:18PM (#24513253) Homepage Journal

    COBOL itself isn't all that hard. What you also have to know is the stuff that goes with COBOL on a mainframe environment like CICS (pronounced 'kix') and so forth. And then there's the difference between theoretical knowledge and real world experience. It's one thing to learn C by reading K&R, it's another thing to apply that knowledge to writing a real application or a piece of system software.

    Just because you can learn COBOL doesn't mean you can match skills with some of those 90,000 coders.

    (Spoken by someone who actually knows COBOL, and has actually written a real-world application in COBOL).

  • by polar red (215081) on Thursday August 07, 2008 @02:24PM (#24513365)

    yeah, as a software archeologist myself, i can testify that old systems still need maintenance: new laws, changes in organization, new products,... that means that those old systems all need continuous 'fine-tuning' - no administrative program really is 'complete'; to make matters worse: those systems get more and more complex. While a complete rewrite could save money in the long run, in the short term this would be very costly.

  • I am happy (Score:2, Interesting)

    by Mong0 (105116) on Thursday August 07, 2008 @02:33PM (#24513477)

    I am so glad that COBOL is not a sexy language. Why? Because it keeps the majority of coders out and keeps the need for developers at a high premium. This allows those of us that know COBOL and actually enjoy coding it to laugh all the way to the bank.

    I have been coding COBOL/DB2 for ten years now and have never once felt that I could not get another job doing the same thing making the same or more money.

    You can make the statement that COBOL is a dead language all you want but banks, insurance companies, telecoms, energy companies, etc. will continue to use and develop new project around COBOL because "no one has ever been fired for going blue".

    You go ahead and continue to develop your little web apps and I will know I have a stable job out look for the next 30 years.

  • Re:I don't get it (Score:5, Interesting)

    by mwvdlee (775178) on Thursday August 07, 2008 @02:36PM (#24513539) Homepage

    I'm a full-time COBOL programmer with a history in Java professionally and C/C++ and a number of other languages in my own company.

    COBOL isn't hard to learn. It certainly isn't much more difficult than any other modern language.

    The hard part is that COBOL really doesn't help you much. In most modern languages you can just grab a library containing a complete linked list or efficient sort algorithm. COBOL programmers actually need to know how stuff like this works. Now maybe you're an exception, but surprisingly many Java developers don't know the first thing about basic algorithms and memory structures like that. Add to that the need for high performance (the cost of running a COBOL program is often charged by the minute and measured in fractions of seconds), high stability (I've worked with code which could bankrupt a company if not fixed within a week or so) and the complexity of the typical Mainframe environments COBOL runs on, and you can see why it isn't trivial to start working with COBOL.

    The language is easy, using it is not.

  • Re:I don't get it (Score:3, Interesting)

    by pauls2272 (580109) on Thursday August 07, 2008 @02:47PM (#24513771)

    It's not hard to learn COBOL. I think there is even a COBOL for DUMMIES book. If not, I'm sure there is a SAMS learn it in 24 hrs book.

    The problem is being book learned is nearly useless. You need to have a skill set to know what VSAM, flat files, etc are. What JCL and TSO is and how to use it, etc. This just to get to the point where you can actually look at the code and compile it.

    Now, if your looking at a good piece of structured COBOL code, changing it isn't too hard. The problem thrown in your way are usually administrative - it takes 4 hrs to actually code the change but 4 weeks to do all the documentation of the change, QA, change control, etc to get the code into production.

    Now, if your looking at a bad piece of COBOL code, then it could take a very long time to even figure out what is happening in the program. But this no different than trying to update a poorly written piece of C code.

    Imagine needing to update a very complex poorly written piece of Code say of the complexity of Nethack (source is freely available). Now suppose there there is little or no doc to the code and you are fresh from a book on C. I think it would take you a long time to make a complex change to the source code.

    So at that point the language is basically irrevelant.

  • by MBCook (132727) <> on Thursday August 07, 2008 @02:48PM (#24513801) Homepage

    DeVry does, or at least did, a few years ago. I should know, I took the class. It was an upper level course, and part of a set of required electives. You had to take COBOL or (something) or (something). I don't even remember if the other two were languages or theory or what. But it was there. All campuses don't have to teach it, it is market driven. Having a very large and old telephone company not to far away means there is some demand for people who have had some exposure to the language.

    As some others here have commented, COBOL is amazing. I learned programing through BASIC, HyperScript, C, Java, and other languages. COBOL is so primitive in so many ways. It feels a bit like trying to use your knowledge of Romance languages to decipher how to say something in Japanese.

    Now this makes sense, as COBOL was designed so long ago for machines that only had punch-cards and such. But for most any student who learns programing these days to be given COBOL is going to be a huge logical shift.

    And that doesn't include the syntax. Ignoring the special columns and such, no modern languages are very close to COBOL's syntax.

  • by Rastl (955935) on Thursday August 07, 2008 @02:53PM (#24513909) Journal

    If I'm told by my company to learn COBOL and it's on their dime, I'll learn it. Why should I care one way or the other? It's just another language to know.

    Zealots aside, if it's needed then learn it. It might not be as 'sexy' as the newer stuff out there but if it keeps me employed and puts me into a hard-to-do-without niche I'm perfectly happy.

    Then again I may be the exception in that I'll learn anything my company needs me to learn. There's a few languages I've learned on my own, for my own reasons, but overall I'll take any training they're willing to dole out. Kind of like the reward pellets. I'll keep whatever I learn no matter where I go so I don't see a downside.

  • by johnlcallaway (165670) on Thursday August 07, 2008 @03:10PM (#24514265)

    Payroll is one of the BEST applications for COBOL. It's very table driven and procedurally oriented. There are very specific discrete steps to be taken when calculating gross pay, pre-tax deducations, tax deductions, and final deductions. Then calculate where the net pay is distributed via EFT or paycheck, create files or print checks, and you are done.

    I managed a COBOL based payroll system back in the 80s with green-screen interface, and it was one of the easiest systems to work on. It was written in discrete elements that were easily changed without impacting other programs. New programs could be easily added into the stream. Any system that is well designed can be simple to extend.

    That crap about not being able to roll back sounds like someone who doesn't know how to write maintainable code. And anyone who doesn't do backups (or make sure the daily ones were done) before installing new code is an idiot.

    I just got through migrating an 8 year old C++ system to Java because it was an abysmal failure that no one wanted to touch. Replaced 12 programs that basically all did the same thing with 1 program and 2 stored procedures, reduced complexity, and increased flexibility.

    No language is immune to bad development.

  • I agree; the stuff worked well in old systems. It was optimized to save CPU cycles and disk space...It was a conscious decision which made good use of the resources of the day.

    Unfortunately that day is gone. We should focus now on code reliability and maintainability and COBOL is not great in those areas. Trying to write in intelligent failure into a COBOL app is a nightmare compared to JAVA where it's almost the backbone of the whole language.

  • by mattwarden (699984) on Thursday August 07, 2008 @03:28PM (#24514617) Homepage

    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.

    State governments are paying millions and millions of dollars to replace their legacy COBOL based systems, so the question of "Why replace it?" has some pretty convincing answers...

  • Re:I don't get it (Score:3, Interesting)

    by johnlcallaway (165670) on Thursday August 07, 2008 @03:29PM (#24514639)

    You mean like all the senseless boilerplate crap that you have to use to write C++ GUI programs on Windows??

    Crap is crap, either learn it to do your job, or go find another job because you aren't clever enough.

    And, just like with C++, once you create a template, it's just fill in the blanks. I had four COBOL skeleton programs back in the 80s that I used, and they covered 90% of all the programs we wrote. The great part was all the programs had the same structure, so a program I wrote was easily understood by someone else.

    One of the developer came to me one day and explained a problem he was having. He started to hand me the printout, and I told him what the problem was without even looking at the code. Why?? Because all of our programs looked the same. And I had made the same error before.

  • Re:Highly unlikely (Score:4, Interesting)

    by PRMan (959735) on Thursday August 07, 2008 @03:31PM (#24514667)

    a return to the statement-based languages of yesteryear might actually be a good thing: let the coder get on with writing his code, and let the interface builder do all the fancy OO stuff.

    Not hardly. I just rewrote a VB 3-6 application into C#.NET because nobody can compile it anymore (requires a 16-bit tab component and nobody has VB4 16-bit install disks, let alone floppy drives even if we did).

    The original application was 13,000 lines of BASIC, written (mostly full or half time) over the span of 11 years. The new C# application is 900 lines and has MORE functionality (not to mention nice commenting as opposed to NONE) and I wrote it in 2 months.*

    Return to the bad old days of underpowered languages that require thousands of lines to read a database and display it on the screen? No thanks.

    *BTW, this brings up a good point. Just because some company has 9 million lines of COBOL doesn't mean that the programs couldn't be replaced with 500,000 lines of an OO language.

  • by raftpeople (844215) on Thursday August 07, 2008 @03:32PM (#24514695)

    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?

    The voice of experience. I'm constantly amused by posters who think they "know" the answer and it's so simple, everyone else must be dumb. Yet they've never had to execute a project of that magnitude. This entire topic really has very little to do with COBOL and more to do with the issues you raised (as well as the numerous other ones that will be discovered as you walk through each of the questions you listed).

  • Re:COBOL has loops? (Score:3, Interesting)

    by LMacG (118321) on Thursday August 07, 2008 @03:39PM (#24514817) Journal

    > Unless you consider GOTO a loop constructor...

    Why not? Ultimately, the compiler is going to produce the machine language equivalent of a goto anyway, so what difference does it make if you have to hand code the initialize, test, iterate portions of a loop or if the language has it all packaged up for you?

    Granted it's been over 20 years since I worked on a COBOL program, but the last guy I worked for had developed some pretty decent coding standards that let us use a fair amount of structure in our programs. It wasn't perfect, but I know for a fact that the number of late night phone calls I got went way down after learning to do it George's way.

  • by SirLurksAlot (1169039) on Thursday August 07, 2008 @03:54PM (#24515179)

    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.

    The language itself is fine. Yes it's verbose, and yes it's old, but it does what it needs to do, which is solving business problems. Look, you need to keep a historical perspective here. COBOL was created back in the "bad old days" before all the best practices were written, because at the time they were still being written.

    Basically, they're comfortable with their crusty old bugs, and they don't want to deal with scary new bugs.

    Ever heard the phrase if it's not broke don't fix it? By your logic we need to pull out core modules in the Linux kernel just because they've been in there for 10+ years! (Note: I don't actually know what the lifespan of code in the kernel is, but you hopefully get my point.)

    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.

    Not to ruin your rant here or anything, but you're comparing a modern language using a modern transactional db with a legacy language using a legacy db. Of COURSE you're going to see a difference in your ability to recover from a failure! It's not as if you can't code for a proper recovery in COBOL if you're using a modern transactional db on the backend.

    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.

    I think you're forgetting why most of us are employed as developers. 95% of us (I'm speaking about employed devs, mind) are not here to write code simply to write code, we're here to solve problems, and most of the time that is for a business that is out to make money. Also most of the time if there is no business case to update the code then it doesn't get updated. As for outdated models, how is it outdated if the model still serves it's purpose?

  • by polar red (215081) on Thursday August 07, 2008 @04:08PM (#24515483)

    Rewriting software should always be the last resort.

    not if you could go from COBOL to a language that supports classes, or even just more modularity would be great ...

  • Re:I don't get it (Score:4, Interesting)

    by jd (1658) <<moc.oohay> <ta> <kapimi>> on Thursday August 07, 2008 @04:17PM (#24515655) Homepage Journal
    Cobol was never a good language, and computer scientists fought hard to move the industry away from it because the probability of writing defective code was extremely high. It is readable, but really only in the same sense Intercal is. There are many, many hundreds of programming languages out there with far more programmers in each than Cobol has ever had. Use what makes real sense, not what some medieval history teacher thinks ancient civilizations may have liked. Hell, ADA has more merit - and more support for modern capabilities. If people are really serious about Cobol, I'm going to write an Algol65 plugin for Firefox - see how people like Algolscript pages. Nyah!
  • by doupatex (660577) on Thursday August 07, 2008 @05:03PM (#24516465)

    I've rarely ever seen good COBOL, so maybe it's possible. From what I HAVE seen, especially with the never-to-be-sufficiently-cursed KSAM flat table POS wannabe database files, suggests to me that good, recoverable, code, is nearly impossible to write. None of that stuff is transaction safe. The programs work in too many discrete steps; if it fails, it hardly ever fails in such a way that you can just RE-run the program; either you need a recovery-specific subset or you have to traverse the program until the point of failure and see if you can recover it.

    It is possible to write good COBOL :-)

    In the programs I maintain, the recovery is per-program or per-job. Each "unit" of work has a documented (albeit manual) rollback. It usually implies replacing the trashed files from a backup tape (*).

    Manual well documented recovery has an advantage : it requires that someone actually looks at the problem and finds why it crashed.

    (*) Yes, we don't have a relational database on our mainframe. Only flat files. With 8-chars names. And no hierarchical filesystem. It's called "DOS/VSE with ICCF" and it's so old I feel like a caveman, which is actually kind of fun sometimes :-)

  • The language itself is fine. Yes it's verbose, and yes it's old, but it does what it needs to do, which is solving business problems. Look, you need to keep a historical perspective here. COBOL was created back in the "bad old days" before all the best practices were written, because at the time they were still being written.

    I don't see that this has anything to do with whether COBOL is an OK language. This means that it was an OK language (or maybe even a good language) in the "bad old days", but Moore's Law has given us the luxury of having much higher standards now.

  • by jandersen (462034) on Friday August 08, 2008 @02:15AM (#24521453)

    We have been predicting the demise of both COBOL, FOTRAN and mainframes for how long, now? Decades? I have suspected for a long time that we are not going to lose them any time soon - COBOL is certainly no beauty, but it is proven and seems rock solid. And it is not even all that bad a language to work with, although I must admit it looks rather painful, doing anything but simple programs with it. Still, I worked with COBOL for years - and enjoyed it too.

    The same goes for FORTRAN: an ugly language with some horrifying features; but one that has a huge, old code base in the science community - because it was first, but also because it has the exactly the features you need for numeric programming. A bit like a meat cleaver - not a thing of beauty that your girlfriend would have on her make-up table (depending on your relationship, of course), but functional and to the point.

  • by donaldm (919619) on Friday August 08, 2008 @03:14AM (#24521685)

    Or, better idea, translate all the COBOL to C++ []. No teaching needed.

    Actually the link you provided has converters from COBOL to "C", "C++", "Java" and "C#". If these converters/filters produce anything like the output of yacc and lex (open source bison and flex) then the code while runnable is more or less unmaintainable but not to worry you have a job for life if you want ;-)

    If you read the following [] the best quote on cobol is as follows:
    Critics have argued that COBOL's syntax serves mainly to increase the size of programs, at the expense of developing the thinking process needed for software development. In his letter to an editor in 1975 titled "How do we tell truths that might hurt?", computer scientist and Turing Award recipient Edsger Dijkstra remarked that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense".

    Hey it's a quote so please don't shoot me!

"Tell the truth and run." -- Yugoslav proverb