In this second installment in our series, “Cobol is dead…seriously,” we will help managers understand that there is a major distinction between tools and techniques and that the techniques used in building software may actually be more important to maintainability than the tools used - in this case the programming language. We will continue to use Robert Mitchell’s article, “Brain drain: Where Cobol[i] systems go from here[ii]. Mitchell interviewed a number of IT managers and technical architects to get an industry perspective for the reasons some organizations may want to move away from their Cobol investment. The myth we will debunk is the notion that Cobol programs need to be replaced because they are more difficult to maintain than programs written in other programming languages. Say what? … seriously? I find this pretty difficult to believe. On the Dave D MythoMeter it appears to be a myth. Let’s continue by establishing an enterprise perspective for our thinking.
Image Source: http://assets.devx.com/HotList/250x250_Cobol.jpg
In large global enterprises, computer programs represent the encapsulation of the organization’s business rules. Enterprises use computers to do work; so computer applications are called “workloads.” This is a very different perspective from personal computing where many of us use computers for entertainment or non-enterprise applications where the results of our computing activities are often inconsequential. To illustrate my point, my Google search didn’t give me the exact results I was looking for and my Facebook status posting took more than 10 seconds and wasn’t quite accurate. I think I can make it through the day, don’t you?
Enterprise workloads; however, mirror or should mirror business processes. Think high volume, high volatility, and complex workloads that require high performance. Consider workloads like processing customer orders, managing inventory, processing payroll to pay our employees, processing our credit card transactions so consumers don’t need to carry cash, or keeping track of our customers and their activities so we don’t have to remember millions upon millions of records of data. Enterprises use computer applications because many of these business processes are complex, repetitive, can be done faster, more accurately, or remembered longer than if performed by humans. If the average knowledge worker is like me, they don’t want to do manual, repetitive or tedious tasks, anyway. Mitchell continues to provide us with many examples where Cobol applications are slated to be rewritten in other programming languages and as our author suggests the language of choice for Cobol’s replacement appears, in most cases, to be Java. I have no quarrel with Java, after all, I am a Java programmer and have built many Java applications. The issue here isn’t about which tool is better, Java vs. Cobol, but is the language’s constructs the major attribute responsible for its maintainability?
Mitchell shares one perspective from the New York Stock Exchange’s (NYSE), chief architect and chief data officer, Steven Hirsch. Hirsch contends that Cobol is not easily changeable. Sound like a myth? Hirsch’s statement addresses the fundamental maintainability of NYSE’s Cobol programs. Is Cobol at fault?
Image Source: Bloomberg.com
Hirsch's second reason is that Cobol programs are tied directly to a specific hardware and operating system platform, specifically IBM zSeries servers and the z/OS operating system. Sound like another myth? So Cobol can only run on IBM zSeries servers running the z/OS operating system? Hum … interesting position but I’m finding this a little hard to believe. At one time could I have lived in Missouri? Again on the Dave D MythoMeter sounds like another myth. There will be more on computing platform dependence issues in future blogs.
Addressing Hirsch’s first point, Cobol programs are “…not easily changeable,” his words not mine, would lead the reader to believe that the Cobol language lends itself to producing un-maintainable code. Not to pick on Hirsch, but as Mitchell’s article indicates there are other IT industry professionals that share the same misconception. The facts; however, just don’t support Hirsch’s argument. While I do agree that the tool, the programming language, has some effect on program maintainability, I would argue that maintainability is far more a function of technique. Consider the following: system design, program design, programming standards (think cohesion and coupling here,) program size, application and program complexity and naming conventions (data set names, data names, function names) do any of these have implications on maintainability?
I think it is safe to say, any program, can be written in any language to be maintainable and of course the opposite is true as well; any program can be written in any language to be un-maintainable. My premise is that programs that undergo strict design and then are written by fully competent professional computer programmers, software developers or software engineers will generally produce highly maintainable program code. Programs that our author addresses in his article may have either skipped the design step or their programs may have been developed by programmer amateurs, or maybe both? In either case I’ll assume that the program design step was bypassed in order to produce something that “kind of” worked without regard for the program’s maintainability. For those that have taken my systems analysis and design course or a programming course from me already know that maintainable program code starts in the “design” phase of the systems development lifecycle. If programs don’t meet maintainability standards, then the systems designers must have skipped program design and gone right to the build step in the implementation phase. Why do competent IT managers allow that to happen? Tell me what you think.
In the next installment we will describe a couple of programming languages, Cobol and Java, in more detail and look at some code examples. We’ll let you be the judge. So stay tuned.
Tell us your thoughts in the comments section!
Dave Dischiave is a professor at Syracuse University’s School of Information Studies and the Director of the Global Enterprise Technologies Programs. His areas of interest are in large scale systems development and integration and the development and use of large data structures.
[i] Cobol - Common Business Oriented Language developed in the late 1950’s and still in use today, http://americanhistory.si.edu/exhibitions/small_exhibition.cfm?key=1267&exkey=988&pagekey=989
[ii] Mitchell, Robert L. "Brain Drain: Where Cobol Systems Go from Here" Computerworld. Computerworld, Inc, 14 Mar. 2012. Web. 14 Mar. 2012, <http://www.computerworld.com/s/article/9225079/Brain_drain_Where_Cobol_systems_go_from_here_ >