When people mention COBOL, it's usually either met with a scoff or a groan, conjuring up unimpressive images of programmers trying to maintain mission critical business applications using thousands of lines of code. The antiquated language no more enjoys the lionized position that it did a few decades ago. And with reports of its waning popularity making rounds every few years, one may want to revisit its relevance in the current scenario.
As someone who started her career with COBOL, I cannot fathom all that scorn. I feel much of the contempt it attracts is highly unwarranted. True, it is more than half a century old and many advanced languages have emerged since. But, COBOL continues to be the BEST at what it was actually made for: iterative programming and batch file processing.
Let's set the record straight. COBOL (COmmon Business Oriented Language), was actually designed for developing large business (typically file-oriented) applications, as the expanded acronym indicates. It was not designed for developing system programs, like developing an OS or a compiler. 50 years ago COBOL was best for large organizations having lots of data to manage. It underpinned the core of banking, finance, insurance, government and healthcare applications. Yes, COBOL's procedural paradigm doesn't suit today's networked environment, where objects and layers make more sense. But it has nothing to do with the language itself, it served us very well when there was ONE central processor & no event-driven programming required. COBOL is still splendid where procedural, rather than object-oriented, paradigm is adequate.
The reluctance can largely be attributed to the collective bias that equates anything "old" with "irrelevant" or "useless". Most have a very uninformed and skewed perception about how COBOL works:
You say it is no longer relevant? That there are better ways to manage large volumes of data today? Show me a good C++/Java/Ruby/Python developer put together a program to do something like print a fifty million transaction history statements with accurate summaries as quickly as a COBOL programer of similar skill and experience can. Some problems are best solved by COBOL. Bulk record processing & account reconciliation are two of those. It is still the basis of many great interactive applications, thanks to OLTP systems that provide "real time" transactions on top of legacy batch procedures. Although these are supported by several languages, COBOL is where they find their natural home. Not to mention the cost of transactions in COBOL, which is estimated to be 5 times lower than it would have been otherwise.
You say it is not object-oriented? COBOL has not been static. It has grown and evolved over the years and is as capable as any other general purpose language. It now has OO features. It runs on virtually any platform. I have worked on COBOL systems that run on Unix, Windows as well as Mainframes. COBOL is just one of many programming languages and is not any less capable because of its specification age or the platforms on which it can run.
You say it runs on an inferior database? Web server? UI? You can run it on DB2, Oracle or any other database. Web interface to a COBOL system - you inadvertently interact with them every day. As for the code looking old, you can anytime pair it up an attractive UI or a web interface. No one can tell the difference. As it is, there won't be many new exploits for COBOL softwares, since it is primarily used by large businesses, not by an average person.
You say you can't scale the system? COBOL is highly scalable. Most new functional requirements can be easily retrofitted in the existing running system. Nowadays, it can also be developed on distributed systems with modern IDEs like Visual Studio or Eclipse. They can be seamlessly integrated into the current technologies and can distinguish themselves at run time, with as much ease as the modern languages. Modern COBOL compilers, can generate native code for Windows, .NET, UNIX, Linux, JVM and the cloud. It now provides all benefits of modern programming languages without incurring additional costs.
You say you need to upgrade the system? For what? Most organizations just don't know why they need to upgrade. They think they do, but after the upgrade they want a program to do exactly what the last one did. Replacing COBOL just for the sake of technical change provides no business value.
The existing robust custom COBOL-written softwares fit the organizations' processes and workflow. Add decades of alterations and enhancements to it. End product is a complex intertwined end-to-end system. It also maintains a decent backwards compatibility. And for all it's foibles, all those trillions of lines of COBOL code actually work. They may be an overwhelming kludge, a result of decades of refinement, but those gigantic black boxes of code work. And there's no reason to think they'll stop doing so any time soon.
You say you can do better? Perhaps you can. But you won't. As someone who worked on some complicated financial softwares, I can tell you this: When it is about financials, companies are justifiably VERY risk-averse. Consider paying tons of money for developing new software, churning out all the bugs of the new software, training people, importing current clients into new software, etc. Also think how many times you may screw up (which you WILL) and how much will it cost in lost productivity? Risk outweighs the benefits of leaving the uncool, stodgy, archaic system. Cost benefits just won't stack up.
The negative image surrounding COBOL is based on some long-standing misconceptions. Truth is, like any other modern technology, COBOL has transformed to meet the requirements of each stage of the development process. There are way too many businesses running on COBOL to be worth replacing or rewriting in other languages. And no, it won't retire any time soon, at least not before you do!
Leave your comments
Post comment as a guest