Cretaceous COBOL Can Spawn Jurassic Java

For many people working on mainframe sites, it was impossible to predict the demise of COBOL.

One minute, it was in the top three programming languages (for around 30 years) then suddenly it is around 30th.

COBOL programmers mostly never saw the approaching comet and the ones who did were viewed with suspicion by the Priests of COBOL whose job it was to protect the sanctity of the Holy Source Code. Deep within Fortress COBOL, innovation and change were not accepted gladly; rather, any form of heresy (like using Relational databases instead of indexed files) was immediately nipped in the bud and ridiculed by the use of arguments about efficiency, ghastly overheads in RDBMS, and the inexorable and irrefutable: “We’ve ALWAYS done it this way and it works.”

Life was pretty good for the Knights COBOLLers.  They lived behind a magic waterfall which provided seclusion from the annoyance of having to write applications. Mostly, they could treat the Holy Mainframe as if it were their own property and spend time checking out new packages and software that would look good on a résumé.  Writing COBOL is actually fun, so even when real work had to be done, it wasn’t so terrible. And nobody outside of IT understood what they were doing anyway…

It was a heady time when Computer Science was still a toddler and practical experience was everything. People received a two week COBOL course and became “computer programmers”. (Many of them did the job very well but, without “best practice” guidelines, and allied with COBOL’s “English like” propensity, there was a tendency to devise logic in muddled English and, after a few years of various practitioners taking their own crack at it, the result was code that no-one dared maintain.)

The Waterfall ensured that anything that was delivered was at least six months out of date and the business received “something like” what they had requested during “Requirements Gathering”  which may have been a year ago.  This led to the situation where the business would accept the new system and immediately have to request amendments to it. These requests made the COBOL people feel unloved and unappreciated so they slunk off behind the waterfall and took their time getting the new enhancements implemented.

Robert Townsend in his 1970 Novel “Up the Organisation” summed up the IT department as follows:

"Most computer technicians are complicators, not simplifiers. They're trying to make it look tough. Not easy. They're building a mystique, a priesthood, their own mumbo-jumbo ritual to keep you from knowing what they - and you - are doing."

It was pretty fair comment for the time. (Some would say we haven’t changed much, but I like to think we have; there is a big difference between prototyping new functionality or deriving Use Cases with users in a JAD workshop or Agile scrum, and having an “IT only” meeting to develop a task oriented PERT Network that decides when the next milestone on the waterfall should be delivered…)

PERT (Program Evaluation and Review Technique) was developed to support the Polaris submarine building program.  Hardly surprising then that many waterfalled IT projects end up torpedoed or submerged…

The IT world changed in the early 1980s with the advent of a desktop personal computer/workstation and the development of the Relational Data Model.

Kids started programming in BASIC. The “professionals” heaped their derision on the new “toy computers” that could never possibly take on the business loads handled daily by the mainframe.

Then people started connecting computers together so they could share information and have more processors available. The “network” grew rapidly in power and strength and the “Internet” (a network of networks) emerged.

The procedural paradigm, which had been ideal for a centralised single processor, was overtaken by a new paradigm where, instead of everything being controlled from  centralised code, events occurred and were dealt with immediately in real time, by small, encapsulated “objects” that could be re-used and even flashed around the network to  different processors so that loads could be levelled.

Functionality could be viewed as “Classes” of code which contained attributes and behaviours and communicated by means of an interface which kept the “internals” isolated from the environment. Code development became “component based”. Systems were built like Lego; very quickly from components already available. The old days of “knock on” errors in monolithic code became a thing of the past. A one line change in a COBOL program could have consequences down the processing chain, many thousands of lines of code away from where the change was made.  Languages using the new OO paradigm did not suffer from this to anything like the same extent. Everything communicated through interfaces and there were layers and separation of functions like Presentation, Business Logic, and Data Access.

The programming world was abuzz with words like “Object Orientation”, “Polymorphism”, “Method Signatures”, their own jargon that made it possible to swap ideas across different programming languages. Methods and properties were the same whether you implemented them in Java or C++ (and, a little later, in C#).

The new world was far removed from COBOL and the COBOLLers watched from their Fortresses as the Barbarians on their lighter faster ponies, simply overran the world.

Programming languages, scripting languages, web development; the world voted with its feet and embraced the OO paradigm.

Object Orientation WAS added to COBOL around 1990 but IBM did not implement it fully and it fell to companies like Micro Focus and Fujitsu, who were providing compilers for the workstation platforms, to do a proper job of it.

Sadly, the COBOL community mostly did not embrace it and the reasons for this are complex and manifold. The fact is that COBOL missed the OO boat and now there is some frantic paddling to try and catch up. Modern languages like Java and C# are moving to fill the space and most of the early hesitation about commercial software development in OO languages has proven to be groundless.

Here in 2012, a new generation that has grown up with computers is arriving in the workplace. They know about spreadsheets and databases and use applications easily. It is as if the mysterious role of the COBOL Priest was subsumed as soon as everyone could read the scripture for themselves.  Within the Fortress though, the web is awash with wailing and gnashing of teeth on big business sites over the decline of COBOL and where to go next.

I was recently reading an article on the Computerworld site that seems to think the decline is being forced because the world’s COBOL programmers have all turned into old codgers and will be retiring soon.

It isn't a "brain drain" on the part of COBOL programmers that is causing the problem; it is failure by senior management to stay in touch and recognize that there is a sea change going on. It isn't like it happened overnight.

For over 20 years now it has been apparent that the paradigm has changed.

Management should have seen what was coming and planned for it YEARS ago, long before Y2K.  (To be fair, in many smaller organizations they did; it is the big outfits who believed they were immune. Those same outfits are ponderous, resistant to change, and now wondering where to go next. So what do they do? Blame the programmers. They're all retiring... Gee, who could have predicted that?)

I can't find much sympathy for the leader of a major Bank who employs a couple of hundred COBOL guys and responds to the problem by deciding that they will keep on doing what they have always done. Or an IBM guy (with an obvious vested interest), whose attitude is "nothing to see here" and who patently doesn't get it either. No imagination, no solution and no grasp of what the options are. Same old, same old... buy a new compiler, we'll look after you in COBOL...

Various tools have been developed to convert COBOL into Java.

(Search hint: COBOL into Java)

There are even COBOL compilers that emit Java code.

(Search hint:  COBOL compiler to Java)

The problem with that is that if you input Cretaceous COBOL you will get Jurassic Java.

Management generally doesn’t understand why it matters, but programmers do.

You still haven’t addressed the paradigm clash and you can’t get a worthwhile solution until you do.

Simply re-hosting COBOL on a network is NOT a complete solution and only a blind fool would think it is.

You might save some hardware costs but you still haven’t addressed the real problem.

Converting existing procedural code to Java is also NO solution and any decent Java programmer will tell you WHY it isn't. It's like whisky and water; ruins two good things.

If there are priceless "untouchable" nuggets of business rules encapsulated in COBOL in the existing systems, the people to deal with that are the existing programmers who understand the Business. It isn't about outsourcing it to coders who have no knowledge, understanding, or perception of the business, just because they will work for $8 an hour...

Moving on from COBOL is NOT just a coding exercise in ANY language. If there is no strategic vision and the people tasked with making the decisions have no idea what is involved, how can it be anything other than a fiasco?

They need to look at the options and tools available, get skills and knowledge transfer going on while they still have people on site who understand the code, and they should be ensuring that the "rising generation" of programmers are involved with the legacy systems.

It isn't hard for a modern programmer to learn the COBOL they need to know, and the best way to learn it is to work alongside an "old timer" who not only knows the language but knows the applications and the business. Certainly, the old timers may never understand OO or even want to, but the new breed do and they CAN re-wrap COBOL to migrate it, where it makes sense to do so. It is also possible to build COBOL Classes which incorporate the legacy functionality and can interact with any other OO language.  There are tools and compilers to help with this.

One example of a company that provides this technology is Micro Focus, who's been providing COBOL compilers for the PC platform ever since 16 bit computing. They have a tool called Visual COBOL, which is a fully OO .Net compiler that can be useful for refactoring legacy COBOL. It gets legacy programmers used to using a modern IDE and thinking in terms of Classes and Objects. Because it is a CIL generating compiler, Classes developed with it can be used by any other .Net language and also by Java. 

More examples: (Search hint:  COBOL Eclipse)

COBOL CAN be salvaged and it can be “objectified” so it can play on a level playing field like .Net or Mono, and interact properly (and seamlessly) with more modern OO languages,  but the first questions should not be about technical options, they should be about functional options. Can you afford to write off the existing COBOL investment? If not, how much of it is essential to your business? Focus on what NEEDS to be salvaged and get people working on that.

There are more tools arriving every day that can help you refactor your existing COBOL. Other Toolsets extend the life of the COBOL legacy allowing it to be useful for longer and buying you time for new development and migration.

(Search hint: Refactoring COBOL for the 21st Century)

It isn't about a "war" between COBOL and Java (to be frank, that is no contest...), it is about programmers with different training and backgrounds working together to leverage old systems and salvage what is useful, in order to bring timely functionality to the business.

And it needs managers who understand what is important and don’t just formulate strategy based on what some journalist wrote in an airline magazine.
The important thing here is not about what language you move to (some people simply buy a package), it is about ensuring that FUNCTIONALITY (and that includes functionality buried deep in legacy COBOL systems) is made available to the business.

Java guys may find having some COBOL skill or knowledge to be advantageous to them, especially if they are working in large organizations that are still running mainframes.

There is a place for COBOL (especially alongside Java) in today’s world but it is not the same place it held in the last century.