COBOL Turning 50, Still Important 314
Death Metal writes with this excerpt from a story about COBOL's influence as it approaches 50 years in existence:
"According to David Stephenson, the UK manager for the software provider Micro Focus, 'some 70% to 80% of UK plc business transactions are still based on COBOL.' ... Mike Gilpin, from the market research company Forrester, says that the company's most recent related survey found that 32% of enterprises say they still use COBOL for development or maintenance. ... A lot of this maintenance and development takes place on IBM products. The company's software group director of product delivery and strategy, Charles Chu, says that he doesn't think 'legacy' is pejorative. 'Business constantly evolves,' he adds, 'but there are 250bn lines of COBOL code working well worldwide. Why would companies replace systems that are working well?'"
Cool (Score:5, Interesting)
Define "working well" (Score:5, Interesting)
Before I start, I know all too well that you can write good or terrible code in any language. Still, most COBOL code I've seen is written to run well on hardware that is no longer relevant. A recent experience with an ex-coworker illustrated this pretty well for me:
Said fellow, call him "Joe", had about 30 years of COBOL experience. We're a Python shop but hired him based on his general coding abilities. The problem was that he wrote COBOL in every language he used, and the results were disastrous. He was used to optimizing for tiny RAM machines or tight resource allocations and did things like querying the database with a rather complex join for each record out of quite a few million. I stepped in to look at his code because it took about 4 hours to run and was slamming the database most of the time. I re-wrote part of it with a bit of caching and got the run-time down to 8 seconds. (Choose to believe me or not, but I'd testify to those numbers in court.) I gave it back to him, he made some modifications, and tried it again - 3 hours this time. I asked him what on Earth he'd done to re-break the program, and he'd pretty much stripped out my caching. Why? Because it used almost half a gig of RAM! on his desktop and he thought that was abhorrent.
Never mind that it was going to be run on a server with 8GB of RAM, and that I'd much rather use .5GB for 8 seconds than 1MB for 3 hours of intense activity.
So Joe isn't every COBOL programmer, but you and I both know that he's a lot of them. But back to the direct point, how much of that 250GLOC was written with the assumption that it'd be running on 512KB machines or with glacial hard drives or where making the executable as tiny as possible was an extreme priority? Doing things like storing cache data in hash tables would've been obscenely expensive back in the day, so those old algorithms were designed to be hyper-efficient and dog slow. Whether you think that constitutes "working well" is up to you.
Re:COBOL Jokes (Score:4, Interesting)
Re:Oo, oo, oo! I know! (Score:2, Interesting)
Live a passionate life (Score:4, Interesting)
The ranks of COBOL programmers out there are living drone like lives without passion or joy. That's not for me. I code for the love if it.
Design (Score:2, Interesting)
The question is not, 'Does the code work?', the question is, 'Does the code follow good design principles?' If the answer is 'No, the code is not well-designed', then maintenance can be very costly. I like the snippet from this [msdn.com] page:
"I was once told by an instructor in a design patterns class that the Y2K problem wasn't caused by using 2 digits to represent 4. Instead, it was caused by doing so all over the place. While the reality of the situation is a little more complicated than that, the principle is true. If the date handling code had been all in one place, a single change would have fixed the whole codebase rather than having to pull tons of Cobol coders out of retirement to fix all the business applications."
Re:Define "working well" (Score:5, Interesting)
Nice story, but it doesn't say anything about COBOL.
I think it says a lot about The COBOL Way, or at least the way things were done when those ancient codebases were being written.
Re:Oo, oo, oo! I know! (Score:3, Interesting)
Your answer, while maybe true in some rare cases, just shows the ignorance of some IT people to business decisions. Maintaining such an old piece of technology might actually result in higher costs than developing a new system based on current technology. Why?
1. People. Probably the most important reason. Cobol is not exactly a widely taught language. People knowledgable in Java, C#, PHP and other languages are younger, much easier to find and thus cheaper. People with real solid Cobol experience are actually quite expensive nowadays (supply->demand).
2. Extensibility and maintainability. While maintainability might be ok, extensibility is a bitch. Connectors to Web Services? Talking to the myriad of other web apps you have inhouse? Accessing that SAP system you have?. There might be some solutions for every one of those problems. Hell, they even made Object Oriented Cobol a decade or so. But all of these (proprietary) solutions cost much more money than simply using a new language / technology which comes with most of these included.
Re:Adequate Languages (better than) (Score:2, Interesting)
It's more than adequate because it natively handles money data in transparently correct ways. Other languages have to be bent to fit. Integer and double precision data simply do not meet the need, though these days with 64bit integers it is easier to warp integers to be usable.
In addition it let one record right-size fields on disk and tape (in a day when disks were small and very very expensive).
I'm glad I no longer write code in COBOL, but for many years it was the only choice possible for business.
It was amusing in the 60s 70s 80s reading papers suggesting (32bit) integers and double precision (in C or whatever) as an alternative to COBOL data types. I guess the authors never kept their checkbook to the penny or never had as many as 5 billion pennies in that checkbook.
Re:DOH! (Score:4, Interesting)
Believe it or not, there is a LOT of Fortran out there. I've run across quite a bit of it in the past few years. A lot of scientific, engineering and other number crunching apps were written in Fortran, and there's no reason to rewrite them just because they're thirty years old. The apps might have brand new GUI and visualization front ends, but deep in the heart there is some Fortran code encapsulating the domain specific math.
Another reason... (Score:2, Interesting)
Why would you want to replace 2 billion lines of working COBOL code?
Easy...COBOL, while still in use and working well now, is not a language which is still growing...it is shrinking. Nobody would choose COBOL for a new project. The only jobs left for COBOL programming are maintenance. That means that there are no "exciting" COBOL jobs, and that only coders who learned COBOL, not engineers who are good at design or interested in building/maintaining good design.
"So it's old and all you can get is people willing to maintain, not engineer, the COBOL universe. so what?"
Well, what's what is that:
a) over time, code maintained by "coders" rather than "engineers" i.e. those who are simply proficient in a language, rather those with true engineering talent, will degrade. I have worked with both. I notice a trend. Those with engineering talent...a knack for understanding large systems at a high level and seeing bigger pictures, tend to improve the cleanliness, stability, and re-usability of existing code as they fix or extend it, because they look at the big picture and try to make a change such that it works well in the whole system. "Coders" tend to find the location where the logic goes wrong, and make the most obvious spot adjustment to make the problem go away. Even extensions are treated similarly. Hence, with mostly these types of engineers working on COBOL code, those systems are going to degrade over time. This effect can happen rapidly...I've seen it happen to code that was less than 5 years old. The fact that COBOL code still works is probably more a side effect that all coders of that generation had some engineering skills beaten into them. The younger generation with their "learn a language and get paid" mentality will bring that code to it's knees in a decade or less.
(a) implies problem #2:
b) With code which will degrade as younger, less "design" oriented maintainers are forced to take it over, maintenance becomes a primary concern. Yet as the language gets older, and the code ages and begins to break, gaining more of a reputation for being in shambles, there will be less interest in working on it. Meaning that each generation will produce fewer and fewer COBOL programmers, an effect we are already seeing.
Businesses will be content to sit back and look at their well working, low cost maintenance systems, and think that things will always be that way as long as the don't ask anything new of the system that will cause it to need replacing. This is NOT the case. Eventually COBOL programmers will be all but gone, and those that remain will come at a high premium, and there will not be enough for everybody. At that point, the code will start to break, with nobody to maintain it.
This is when businesses will freak out and think "we need to replace this COBOL program with something in a modern language that we can find programmers for." Except that these old systems are probably not well documented at an algorithm level. The best document is, well, the code. So what they will need is simply someone willing to read through the old code and duplicate it's behavior in a more modern program. Well that doesn't sound SO hard..except, wait, what? You mean, in order to port a program away from COBOL, you need an engineer who still _understands_ COBOL? oh, crap...
Re:Oo, oo, oo! I know! (Score:5, Interesting)
Depends. Staffing is one bit of the equation. You've also got to factor in "how easy is it to extend our existing application". Can you tie your COBOL stuff into your customer-facing billing system on your website? Can your call center be updated so the CSR's are all doing data entry on a web app or a "real" desktop application? I'm sure both are possible but I'm also sure both have price structures that are insanely high, but just a notch less insane as "hire a team of devs to dump COBOL"
There is one more thing I'll toss out, but I'm not sure about. Location. If you are located in Bumbleskunk, USA, the talent pool is pretty small and you will have a hard time getting programmers to relocate (after all, if your company sucks, they are basically gonna have to move again to work some place else). I wonder if there is any correlation between "Uses COBOL" and "Is located in Bumbleskunk". In other words, how many companies headquartered in say, Boston or Silocon Valley use COBOL vs how many companies in say Cowtown use COBOL.
Re:Does this add up? (Score:5, Interesting)
You are confusing the amount of development done with Cobol and the number of transactions handled by Cobol systems.
In my experience, the reason that Cobol still hangs on is that management continues to pursue the philosophy of "patch it just one more time" rather than "port it to something more easily maintained". As time goes by and continual patching gets more difficult, expensive and riskier, the amount of development goes down. But the systems are still up and running.
The ultimate in unmaintained systems was one at an outfit I used to work for where they lost the source code. Its gone, never to be modified again. It was lost before the end of the last century and was suspected not to be Y2K compliant. The solution was to write and run a routine on the applicable database to bump all of the date fields back (20 years, I think). Then, another small routine was written to post process the output add the time back. Management is grinning from ear to ear because, unlike all the other apps that cost millions to maintain, this one costs them nothing. As long as those responsible retire before 2020, that is.
Re:Oo, oo, oo! I know! (Score:4, Interesting)
The last CFO i worked for did that. Was hired to 'rescue' the company but instead he ruined the company, fired most of us that stuck with the company even during the dark times. then he left, with a bonus. ( i hear he destroyed the next one too )
1 year later the company filed bankruptcy.
In reality it was the best thing for me personally, it got me out of the slowly dying industry i had been in for 20 years just before the collapse. But the way it went down was just wrong.
COBOL not quite dead (Score:3, Interesting)
COBOL's main drawback was never any real technical issue. It is simply that it can be very tedious to do. Having said that, once you understand it, it is also a very easy language to code in. But there's certainly no reason to throw away the code just because it isn't trendy any more.
Having said that, I do remember working on a site in the UK back in the '80s where the COBOL source to some important routines had long since disappeared, and my job was to patch the binary directly. Now that DOES take a bit of concentration. (Fun, though.)
Not a heroic life (Score:5, Interesting)
> I declined to take the elective COBOL classes.
> I knew enough about COBOL then to know that I
> could not drag myself out of bed in the morning
> to make a living with it.
COBOL also encourages "heroic" programming. At a shop I worked at, they were very disparaging of the new systems using relational databases, and proud of the mainframe COBOL stuff, because it never went down.
If you don't count the 4 times in one year a hardware failure caused critical business systems to go offline for 2 days to 3 weeks at a time while teams of COBOL coders used tools to manually delete and rebuild tables and indexes when various failures caused -extensive data corruption-.
And the corrupt data caused by operator errors in nightly batch processing.
And the recoding to fix a major financials bug that went undetected for 10 years until we compared the numbers on the external PC system.
You see, that was "normal operations." by contrast, when a network failure occurred and the relational systems we built went offline for 45 minutes, and data recovery was "re-run the job", -that- was a disaster caused by the "sloppy PC programmers and their tinkertoy PC systems."
COBOL's great stuff...if you like being paged at all hours to manually fix data.
Re:2 jokes, 1 question (Score:3, Interesting)
COBOL -> ASM -> C would almost definitely be a more accurate translation of the COBOL code.
Just a though
Re:DOH! (Score:2, Interesting)
Re:Does this add up? (Score:2, Interesting)
I think you'll only notice if you join a company that uses COBOL a lot, a financial company generally, and only then if you're employed to help with it. Even then, you'll probably only be interfacing to a "black box" where you don;t know or care what language runs it.
Which is a very good point.
I've been thinking with all this virtualization and such that you could eventually package up all that old COBOL code onto a virtual machine and just port the virtualization software to new platforms. Forever creating a black box of software that "just works" with out any idea of how or why.
If that does indeed happen then there may develop pockets of entire industries over time that are as mysterious and unintelligible as tax code. Now even if you had a black box of software that was contained in a VM it wouldn't mean you could never replace it.
After all, if you can put it under test you could combinatorically determine the function of the software by slamming every combination of input at the thing and cataloging the output... but such an approach would be very expensive and time consuming and it is much more likely future generations will want to add new function instead of rewriting old function.
In other words, you could rewrite that COBOL but it would be impractical and why bother? Unless significant rules of the real world that the software is supposed to model changes. There may be very little call to do such a thing.
Re:Skill Sets are disappearing (Score:3, Interesting)
Re:Define "working well" (Score:4, Interesting)
This is similar to a mantra of continuous improvement: "In God we trust. All others must bring numbers." The point of that saying is that if you want to make a change to the process, you must support your assertions with real metrics.
Re:Define "working well" (Score:4, Interesting)
> I've seen programmers who grew up with Pascal carefully turning multiplies into sequences of adds and shifts. Great, except that something like the Athlon can do two multiplies in parallel, but only one shift at a time (because most code contains a lot more multiplies than shifts), stalling the pipeline.
That strength reduction of multiplication to bit shifting might not be valuable anymore for modern CPUs surprised me, so I looked up the instruction latency and throughput for the Core 2. To see for yourself, download http://download.intel.com/design/processor/manuals/248966.pdf [intel.com] and look at Appendix C.
The timings show that integer multiply, IMUL, is still quite a bit slower from the bit shift instructions (SHL/SHR). So, turning multiplies into adds and shifts is still a Good Thing.
However, these days, a compiler can do this type of thing for you much of the time, so doing the transformation by hand is usually not necessary. Also, since optimizing the source code in this way does take time and decreases source readability, the only cases where people should really still be doing manual strength reduction are in performance-critical code where the compiler, for whatever reason, is missing the optimization opportunity.
---linuxrocks123