Why COBOL Will Never Die
Way back when I was a programmer, COBOL was the language of choice. It wasn’t as much fun as Fortran, which made me feel like a logician, and I loved using Assembler whenever I had the chance. But COBOL did the trick, and we developed some pretty nifty systems with it.
And then it went away. Well, no actually, it didn’t. Despite the arrival of newer languages and the transition away from mainframes, COBOL has managed to hang around. In fact, it celebrated (if that’s the right word) its 50th anniversary in 2009. One reason it can’t die is that there remains a reported 220 billion lines of COBOL code still in use.
Computerworld described a managing director at a bank who is responsible for 112,500 COBOL programs comprising 343 million lines of code that run core banking and other operations. Whew!
In fact, according to estimates, approximately 60 to 80 percent of all business transactions performed worldwide are written in COBOL, and even a bigger percentage if you consider only financial transactions. Big banks, in fact, were one of the first sectors to implement it and may be the last to discontinue it.
Despite the constant call to prepare for COBOL’s funeral, it remains solidly able to handle huge volumes of information. Its strengths have been based in file storage, access, and manipulation of textual data. COBOL excels at taking data from a database or file, crunching it, and spewing out some sort of output. A great many of the applications written in COBOL have remained largely unchanged in the last several decades.
Yet, relative to the systems of today, COBOL has some clear weakness: It’s not the first choice for systems that require graphical interfaces. Purchased applications tend not to be written in COBOL, and some don’t link well to existing COBOL applications. Other languages came along to handle COBOL capabilities along with capabilities COBOL couldn’t handle.
But the biggest threat to COBOL’s future may be recurring predictions, warnings, blogs, and articles (such as, OK, this one) that question its survivability. This understandably makes managers nervous, and they understandably curtail use of COBOL even where its use might be appropriate and seek other languages wherever they can. I imagine that in their place, I’d do the same.
Sooner or later, and maybe sooner rather than later, COBOL’s continued existence is going to create problems as the number of people skilled in its use—and willing to use it—dwindles. Fewer and fewer colleges still teach COBOL and college graduates with COBOL training are in short supply. And those in the know—the skilled and accomplished COBOL techies—have retired, or soon will.
If I were still an IT manager, the COBOL brain drain would make me mighty nervous. But technology is infinitely adaptable and so are the people who use it. Solutions to extend its life indefinitely may yet appear. I’ll see you at COBOL’s 60th anniversary party.
