Skip to main content
No. of Recommendations: 1
Can one still make money on COBOL?

Since Denny asked ... one of the amazing things about the modern IT world is that there is something like 200 billion lines of COBOL still in production ... so much, in fact, that more new lines are added each year through maintenance programming than are removed by retiring applications. So, yes, one can make money on COBOL. The problem is, how? (other, of course, than by the trivial means of being a COBOL programmer or contractor, which is certainly not new paradigm.)

One interesting possibility is translation, i.e., tools that would convert any given COBOL application from COBOL to Java or C# or some such. There are several companies providing tools for code quality improvement in COBOL, i.e., fixing up some of the nasty bits which programmers put in at one time or another, but actually translating to a new language is hard. These same tools *are* used for translating other languages, but there are features of COBOL which makes the translation more difficult.

I think we are getting there, but one of the problems with this category of tool is that one tends to end up with ugly Java or ugly C#. I.e., one has to spend just as much effort refactoring the ugly code to make a reasonable application to live with as one did in the translation. Expensive.

This is why I have been focused on tools which work code => model => code. I.e., process the legacy code, but build a UML model from it. That will be incomplete and not modern, but given that you have people around who know how the existing application works and what it is that it is supposed to do, then extending and refining that model is significantly less work than building a model from scratch. Once the model is complete and modernized, then one uses MDA (Model Driven Architecture) and/or Executable UML (eUML) technologies to generate code in one's desired language. It takes a lot of work the first time around to build the MDA transforms, but once built, one can apply them to new applications with little change, so the big expense becomes the code => model effort. I know of cases where this has already cut the cost of modernization by over 50% over more brute force techniques (not COBOL, but Progress ABL). I don't know of anyone working on this approach for COBOL, however.
Print the post  

Announcements

What was Your Dumbest Investment?
Share it with us -- and learn from others' stories of flubs.
When Life Gives You Lemons
We all have had hardships and made poor decisions. The important thing is how we respond and grow. Read the story of a Fool who started from nothing, and looks to gain everything.
Contact Us
Contact Customer Service and other Fool departments here.
Work for Fools?
Winner of the Washingtonian great places to work, and Glassdoor #1 Company to Work For 2015! Have access to all of TMF's online and email products for FREE, and be paid for your contributions to TMF! Click the link and start your Fool career.