COBOL Will Outlive Us All 318
jfruh writes "Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works. The truth behind that is the reason that so much decades-old COBOL code is out there still driving crucial applications at banks and other huge companies. Many attempts to replace COBOL applications flopped in the 1980s and '90s, and we're stuck with them for the foreseeable future — but the Baby Boomers who wrote all that code are now retiring en masse."
Re:If a technology is outdated, outsource it. (Score:2, Insightful)
You mean one of the first industries to start using computers commercially? Way before your glorious NASA?
Re:Batch (Score:2, Insightful)
It is no batter at 'batch' processing than any other language. The reason there's still so much of it around is that the majority is hacked together spaghetti written by people who should not have been writing code in the first place; tightly coupled code that people cannot easily replace a component at a time. Earlier attempts to replace the code generally failed because they attempted to use the same people who wrote the COBOL systems to write the replacements. It is a language that is used to allow systems to be written by people who should not be coding in general. Yes people write bad code in all languages, but COBOL is an enabler, just as (in other ways) Visual Basic and Perl are.
Re:If a technology is outdated, outsource it. (Score:0, Insightful)
Re:Batch (Score:5, Insightful)
No, the language doesn't matter. It is the fact that the COBOL code is old. When it was popular it was common for organizations to write their own software. This custom written software was molded to fit the companies processes and workflow. Then you add decades of alterations and the software gets very complex, however it nearly covers the full operation.
So now if you are going to replace it, right now it is popular to get these "enterprise" solutions that are so generic that it takes more work to configure it than it does to make new software or port the code in a new language.
As well most organizations just don't know why they need to upgrade they just think they do, and after the upgrade they want a program to do exactly what the last one did.
Every 3 to 5 years. (Score:5, Insightful)
Every 3 to 5 years this topic comes up. It's almost like some new batch of CompSci graduates start to evaluate the state of the industry, and share their "discoveries" with the world. Except it is the same old discoveries couched in modern terms.
Re:If it aint broke... (Score:2, Insightful)
Why rewrite to something that is modular and well designed? Because it is impossible to add any new features to the old system without inadvertently breaking everything else.
COBOL is a work of genius (Score:5, Insightful)
Viewed through the eyes of a modern programmer, COBOL is indeed a joke. A horrible one. It violates nearly every single principle of good language design in what appears to be a misguided attempt to make programming "friendly." A CS undergrad would get a poor grade turning in something like COBOL as a Programming Languages 101 project.
But for a language first specified in 1959 (when computing didn't even have the Integrated Circuit yet), it's a work of staggering genius; they didn't HAVE all those rules of good language design to fall back on! At the time, FORTRAN had been out for all of two years and LISP for one; hardly enough time to have much experience with knowing what not to do, and neither of those languages targeted the same problem domain.
COBOL made modern computing accessible and useful to businesses. It's programs have maintained decent backwards compatibility for about half a century. And for all it's foibles, all those hundreds of millions of lines of COBOL actually work. They may be a disgusting kludge, a result of decades of compromises, but these gigantic black boxes of spaghetti Work. And there's no reason to think they'll stop doing so any time soon. Nor any reason to believe that replacing them would be in any way cost-effective.
Re:Every 3 to 5 years. (Score:5, Insightful)
That's because IT is suffused with a teenage culture that equates 'old' with 'useless'.
Being able to spew the buzzwords related to the newest fad seems to be a requirement for a dev job these days.
It doesn't help that the industry as a whole (especially in the US) seems to prey on young naive workers and likes to keep them that way in order to extract the maximum profit out of them.
Re:If it aint broke... (Score:4, Insightful)
My guess is that a rewrite will not give you something modular and well designed, it will more likely result in a reformatting of all the data into millions of incomprehensible XML files.
Re:Batch (Score:5, Insightful)
That because the cost of retraining people in new workflows is generally higher than the software package to begin with.
If you gut and replace software you have to modify every employee's workflow to compensate. EVERY person has to do their job slightly differently, and no one has the answers as to how it all has to be worked out from the beginning for each part.
That takes months in a small 20 person organization that is flexible and adaptable. It can take years of lost productivity for larger ones.
I am doing it right now. We are gutting our old ERP system to use a much simplier but ultimately more useful ERP system. Everything from sales, accounting, purchasing, warehousing, inventory, delivery drivers, all have to change how they process their paperwork. We basically had the office staff doing 2 days of nothing as we sorted out bugs with the initial data transfer. Now that is done we begin the task of sorting out workflows, new SOPs, etc.
Re:Batch (Score:3, Insightful)
COBOL is not a great programming language, and people who are experts in it are NOT good programmers per se. It definitely worked well back in the days, and we should appreciate its use, but let us not let nostalgia tinge the garbage that was useful a long time ago, and now just sits there as the elephant that no one cares to move around, gently tended by the cheap Asian labour... and has no exploits because it doesn't really move around a lot.
Hire veteran COBOLers, retirements won't matter. (Score:5, Insightful)
It is a bromide perpetrated by ITAA and business groups that we can't find enough programmers to replace the ones who are retiring.
The simple truth is that no one wants to PAY what people are worth, and there is rampant age discrimination:
http://www.itbusinessedge.com/cm/blogs/tennant/yes-age-discrimination-is-worse-in-it-than-in-other-fields/?cs=38549 [itbusinessedge.com]
Be willing to hire, retrain, or do whatever it takes to employ people over 35 and this so-called problem will be
shown to be the chimera that it really is.
Re:If it aint broke... (Score:5, Insightful)
The character set limitations are really platform issues not issues with COBOL or even in most cases the programs written it in. Honestly I have never understood all the COBOL hate. Sure it fails to deliver on its promises of letting business folks write code without any domain specific training in software develop. Just like every other language that has approached that challenge mostly BASIC or Object BASIC dialects.
That said I'd be actually pretty surprised if a good C/C++/Java/Ruby/Python/PHP/whatever guy could put together a program to do something like print a fifty million decent looking telephone bill statements with accurate summary lines for transaction-data as quickly as a COBOL programer of similar skill and experience can. There really are some problems COBOL solves well. Bulk record processing and account reconciliation is one of those things because that was pretty much THE commercial and military logistics application for computers in the LATE 40's when COBOL was born. COBOL as you might expect is quite fit for that application.
Its when people start trying to do interactive applications in COBOL be it CICS or web or whatever it gets silly and forced. It brings to mind various analogies about square pegs for round holes, and threaded fasteners to be deployed by hammer. Its sorta like how people tried to CGI applications in C for a long time in the webs early days. Sure it worked and if C was all you knew I suppose you could get the job done. C is good at many things, large amounts of string manipulation is not one of them; but its something you need for a dynamic website. Does that make C a bad tool, no, it just means its the wrong application for it.
Re:If it aint broke... (Score:4, Insightful)
BTW, this is not a COBOL hate, that is a "if it ain't broke ..." hate.
Argument like there is training required, there will be bug, ... are generally not the cause at all. The real cause is that the company lost the very business knowledge that is abstracted by the software. Worse, most of the time that knowledge has been outsourced to other third party completely.
The 2 problems highlighted could be solved, even in Cobol. They won't be solved, and the reason is not that new software cannot be better, it is that the company has lost the knowledge of its own core business and is unwilling to take any real measure to learn it back. Most of the time, "If it ain't broke ..." is not wisdom, it is a sign of incompetence as bad as "Nobody has ever been been fired for buying IBM".
Re:Batch (Score:4, Insightful)
You miss the whole point if COBOL, which is to provide a language that clearly explains what's going on while it's doing it. That means that a freshly graduated I.S guy can go in and understand what's going on and make changes.
Sure, you can wire God Awful code with it and, I have seen it, but it doesn't take much effort to do it right.
Little development? Hardly... (Score:4, Insightful)
It isn't just the financial sector, its the medical sector, major distributors, casinos, and more, who use mainframes and similar (I work on an iSeries which at our scale is very much a mainframe - especially in reliability). COBOL and also RPGLE (looks like C/Pascal now) form the back end of many systems because of their ease of programming and especially because they are good at business math. Front end we have web facing apps; javascript/php/etc; RESTful services, and more. New development occurs everyday and is far more modern in its application that your aware. It isn't a land of green screens and such, but those do have their place.
The technology is anything but outdated, if anything we are as modern if not more. The key difference is dead nuts reliability, both in code and hardware. Downtime usually is when the site fails.
Yep (Score:4, Insightful)
Re:Batch (Score:3, Insightful)
Out of university he got a job with a company doing contract work for IBM doing guess what? COBOL code maintenance. Now he is living in California making six figures working for a big financial institution maintaining and writing COBOL. Not so useless now, is it?
Money gets paid to lots of people for useless things. Professional athletes, fashion models, and dog groomers for example.
Re:Batch (Score:2, Insightful)
No, COBOL is magical, in that it supports handling of decimal arithmetic as integer, keeping track of the decimal place as a separate operation until the end. That is one of the main reasons that so many financial institutions used it -- no rounding. As far as I know, only PL/I is the only other language with this built in feature, even to this day.
According to Wikipedia [wikipedia.org], the following languages all support an accurate decimal data type in the standard libraries: Python, Ruby, Java, and Objective-C.
Re:Batch (Score:5, Insightful)
... the following languages all support an accurate decimal data type in the standard libraries: Python, Ruby, Java, and Objective-C.
Which is not the same as supporting it in the language itself, either from a convenience nor a performance point of view.