Is COBOL The Root Of All (Technical) Evil?

OK, so I used a tongue-in-cheek title to attract your attention, forgive me. A recent blog about the Boomer retirement phenomenon provoked some comments by a colleague with strong opinions about COBOL's useful life. I felt that his comments raised a topic that is substantial enough to warrant its own place in the blogosphere. The comments read, in part:

" I am a boomer myself ... But as a software architect who has to look ahead and figure out what customers and users want I can't wait for the 3270 green screen boomer generation to retire.  It will allow for the acceptance of a new application paradigm. Those stepping up to the plate will not hesite to dump the COBOL garbage and use modern tools to create modern mobile apps that will finally end the drama of IT as today's business disabler. ..."

In an attempt to surface a provocative issue for broad debate, allow me to play devil's advocate for a moment. I agree about 3270 and would broaden it to include all character-based interfaces - VT, 5250, etc. The interfaces they create do not match the business expectations of today's users. But does that really extend to COBOL as well? Should we all be lobbying our business peers to spend whatever it takes to strip COBOL from our application environments? It is certainly feasible if you have a small amount of COBOL remaining, but firms with large amounts may have a much harder time justifying it. Simply put, our business peers do not care what languages we use - they want, what they want, when they want it. Funding technically-driven change is difficult, which is one of many reasons COBOL is still with us.

COBOL is a tool and like any tool it is entirely fit for some uses, and entirely unfit for others. The point being that adjectives such as better / worse, fit / unfit-for-purpose needs a context (purpose) before we can judge it. It is certainly fit for some purposes or its fate would resemble BASIC, ForTran, and other pre-historic languages. But fit/unfit misses the most important point. Even if we accept that COBOL is unfit for all uses, the problems that arise are: the ubiquity of its use, the cost to shed it, and the business benefit the change brings - as compared to other business-benefits those resources could bring if they weren't tied to a technically-oriented mass-change such as shedding COBOL. This line of reasoning falls away in small shops with little COBOL left, and looms large in large shops and big batch-processing environments.

Let's draw an analogy outside of IT. The metric system of measures and weights is undeniably better than the systems we use in the US, Canada, UK and other geographic regions of the world. Predictions of the wholsale adoption of metric measures in the US date back to the 1920s, with no clear adoption in the foreseeable future. The lack of standards causes problems every day in a global economy, (commerce, space programs,etc) so why haven't we all adopted metric? The reasons are similar to COBOL - the ubiquity of our current system, the cost to change and the perceived business benefit.

Turning back to COBOL - if we had all subscribed to the "shed COBOL" mind-set that was prevalent at the dawn of client-server, we would have exchanged all our COBOL for PowerBuilder. Had we done that, we would now be wondering how we could possibly extract ourselves from 20 years of PowerBuilder development and move to a modern programming language. This is where we come back to the link to Boomers - migrating the language is the easy part - what do you do with your people, skills, operating environment, operations procedures, etc? You can certainly replace them all, but in the spirit of devil's advocacy, we should recognize the true scope of the entire effort.

The implication that Boomers = COBOL and COBOL = Boomers over-generalizes the programming population. Some recent research completed by my colleague Jeffrey Hammond in conjunction with Dr Dobbs Journal showed that lots of 50-something folks are coding entirely in newer languages. COBOL was a miniscule part of the survey. Although we can stipulate that a survey of a mainframe-oriented publication would show markedly different results, we can't equate all Boomers as aging COBOL hippies - I don't have the hair for it anymore. *;-)  The main point about the survey data is that the world is not so black and white, but myriad shades of grey. Some Boomers are Java-heads, some programming newbies are trying their hands at COBOL via academic initiatives. 

So, I'd like to close this by thanking my colleague for his contributions to these blogs, and hope that by placing his remarks in a devil's advocate context, he'll not take offense, and together we will raise issues that elicit broad participation from a diverse set of folks in the blogosphere and Twitterdom.

What are your opinions about COBOL - is it a useful tool, a technology to tolerate and minimize as time goes on? Is it the root of all evil? Or is it some hybrid of all of these? Voice your opinions and please note your role in IT - it will be interesting to see whether (for example) the opinions of programmers varies from applications directors from those of systems architects and others. 


re: Is COBOL The Root Of All (Technical) Evil?

Phil, I encountered an interesting new dimension to this COBOL discussion earlier this week at IBM's Information on Demand event in Las Vegas. At lunch on Tuesday, I sat at a "topic table" focused on "database application development." One of the other folks at the table was a gentleman who I'm sure would prefer that he remain anonymous (I don't think his remarks were for attribution), who owns a company based in a central-US city that has a lot of COBOL and Assembler mainframe programmers. His company is a software vendor, but his remarks were about the mainframe-programmer skills issue and boomer retirement, so I think they are relevant here.He said he'd had interesting challenges in trying to backfill his older talent:1) He had successfully recruited developers from college and trained them in whatever languages he needed them to know.2) But in order to become effective, they needed to "bond" with one or more of the boomer developers and do skills transfer.3) The boomer developers (and as you know, I used to be one) were often reluctant to do this skills transfer - there were many social barriers between the crop of new entrants and these older developers. They didn't like to hang out with each other, etc.4) Furthermore, he had found that even when he got a good person trained up and knowledge transferred, he had trouble hanging on to them. The numbers worked out so that in effect he had achieved no backfill.5) When these folks left, they would cite various reasons, but it seemed to boil down to some combination of not feeling that they fit in, not really enjoying the work, and feeling that they could make as good a salary somewhere else doing something they enjoyed more. He even matched salary offers on occasion, only to be turned down anyway.Kinda makes you think, doesn't it!Mike

re: Is COBOL The Root Of All (Technical) Evil?

Phil, thanks for taking my comment in my (as usual) fairly direct language so seriously. I appreciate it.I guess I was too strong by writing 'COBOL garbage' because my answer to your question would be a no. I tried to be short but COBOL is not the issue. COBOL applications on an IBM mainframe are easy to maintain. I used to be an IBM MVS systems programmer. My software business has a mainframe and provides all its applications for z/OS coded in C++.The issue I take is with mindset. Too many of those who grew up with COBOL, PL-1 and Assembler are too rigid in their thinking even after they moved on to newer languages or into management positions. They are too focused on creating frozen code, tested to death application icebergs in long, overanalyzed projects. If you want an application with zero errors it will soon be outdated and too expensive to maintain. Carr's question 'Does IT matter?' was thus very valid.The future is beyond COBOL/CICS, Java App Servers and iPhone AppStore. I propose that for business applications we have drop the 'program development' paradigm. Application creation has to move into business hands by means of the right tools and embedded lifecycle management.That is a world that most 'boomers' in todays IT departments cannot imagine. That is the issue that I take and 'COBOL garbage' does not just stand for the programming language but for the application development approach. That includes many developers and managers who group up with large Java projects. Most programmed applications turn into legacy apps right after going into production. Mindless IT cost cutting, outsourcing and 'let's play safe with the biggest vendor' does the rest.I guess I will have to return to writing longer comments again, but then they might not produce such reactions. Thanks again for taking up the discussion. It is very necessary!