Why COBOL Could Come Back 405
snydeq writes "Sure 'legacy systems archaeologist' ranks as one of the 7 dirtiest jobs in IT, but COBOL skills might see a scant revival in the wake of California's high-profile pay-cut debacle. After all, as Fatal Exception's Neil McAllister points out, new code may in fact be more expensive than old code. According to an IDC survey, code complexity is on the rise. And it's not the applications that are growing more complex, but the technologies themselves. 'Multicore processing, SOA, and Web 2.0 all contribute to rising software development costs,' which include $5 million to $22 million spent on fixing defects per company per year. Do the math, and California's proposed $177 million nine-year modernization project cost will double, McAllister writes. Perhaps numbers like those won't deter modernization efforts, but the estimated 90,000 coders still versed in COBOL may find themselves in high demand teaching new dogs old tricks."
Who Cares What Language, It Reeks of Poor Design (Score:5, Insightful)
Got that? So if California goes ahead and builds a new payroll system, within nine years -- about as much time as it has taken to get the 21st Century Project off the ground -- the cost of fixing bugs in the new code could exceed the original cost of the project.
If software is implemented correctly, it will stand the test of time.
The fact that there seems to be some hard-coded values or formulas throughout this code is a fair indication that this COBOL architecture did not have the foresight of someone ever changing minimum wage. Where I grew up, minimum wage changed yearly as it was usually necessary to adjust for inflation. Now, if this is an indication of the rest of that software, I would opt for a newer technology. On top of that, I would go to the lead system engineer with a hand written note reading:
The software shall have a management interface for changing minimum wage and cascading that change correctly through all aspects of the software and other machines.
I'll bet this software isn't modularized. I'll bet this software has some pretty low security standards. I'll bet this software requires a client app installed on any user's machine.
Pull your head out of your ass, "dollar amount one
If you're short on funds, you're short on funds but if you're saying it's cheaper I would like to see your pricing chart for usability, stability, maintainability, etc.
Why COBOL Could Come Back
I think there will always be a niche market for every language but if you mean 'come back' like COBOL would become the average developer's language of choice I would curtly retort with a sharp 'ha.'
I don't get it (Score:5, Insightful)
Why do people think it's so hard for a new person to learn COBOL? It's not exactly like learning Japanese: find a good reference book, write a few practice programs, and voila.
I personally haven't needed to learn COBOL, but I see no reason why that strategy I just described, which has worked for me with every programming language I've ever learned, can't be applied here.
"find me a college that teaches it" (Score:5, Insightful)
FTA:
find me a college that teaches it
What kind of college class would teach COBOL except as a historical curiosity in passing? Their job is to teach kids how to design good software and understand theory. You know, with local variables, objects, exceptions, assertions, and stuff?
COBOL used to target 'business systems'. I'm sure there are several superlative programmers doing COBOL work, still, but business systems programmers tend to be the largest area under the curve, and that's not a problem. The Ruby and Python guys can sit several sigmas out arguing about which provides the better lambda calculus, but meanwhile Java is providing most of the features 'average' programmers need.
If there's a lesson to be learned from the article it's that business systems software isn't ever 'done'. You need to be continually modernizing, with good methodologies, or you're gonna get stuck like Cal-e-forni-a one day. That's either a problem or an opportunity, depending on your perspective, but this isn't an industry standing still.
Highly likely (Score:3, Insightful)
COBOL could easily make a comeback, because it's so damn easy to learn. I could train a cuttlefish to write a complex accounts program in COBOL. Heck, I bet even Mike Huckabee could probably manage to work out "Hello World".
Perhaps the reason it may come back is because of the complexity of modern languages. Most OOP variants are horrifically difficult to understand, and a return to the statement-based languages of yesteryear might actually be a good thing: let the coder get on with writing his code, and let the interface builder do all the fancy OO stuff.
Re:I don't get it (Score:5, Insightful)
To expand on your analogy a little:
You get your Japanese reference book, study hard, maybe even get your 1-kyuu certification (I think four years of study for that is typical for non-native speakers?)
So you get a job translating. Your first project is to translate a recently discovered and unpublished early 1900's work written by someone like Touson Shimazaki or Mori Ougai. Good luck!
=Smidge=
The real skill is 'thinking before coding' (Score:5, Insightful)
Or, as I saw on someone's whiteboard once, "It's easier to teach a COBOL programmer C than to teach a C programmer discipline".
Re:No Thanks (Score:5, Insightful)
COBOL is EASY compared to C/C++ or even Java/C#.
That's a strength, not a weakness.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:4, Insightful)
If software is implemented correctly, it will stand the test of time.
Sturgeon's [Ll]aw [wikipedia.org] applies to software -- except probably with the 90% figure adjusted upward as some function of Moore's law [wikipedia.org] and the observations of Fred Brooks [wikipedia.org], of Mythical Man-Month fame.
IMHO, after a couple decades of accretion of existing software systems, poorly implemented and even designed software systems are production reality today. If you don't take this into account, you're dealing with an ideal that will statistically exist only 10% or less of the time, and when it does, only when rigorous administration and maintenance is continuously applied to the software.
Re:COBOL, Web2.0, etc. (Score:3, Insightful)
And what hot young smart kid wants to learn all this for next to nothing pay and the prospect of never using the skills again?
It can be done, however, and whoever has these systems should make it a priority to start finding a good maintainer either by trade or self-taught or make a replacement system.
Re:I don't get it (Score:3, Insightful)
This is why I said learning a new programming language was NOT like learning Japanese. True, legacy systems use older versions of a language. But there are still a limited number of commands which are well-documented.
I work with legacy systems a little (but not COBOL) and I say this from experience: deciphering someone's shitty programming style in an antiquated language sucks. But it's doable with little training in the language.
no decent statistics (Score:3, Insightful)
I'm having problems following the money on this article. Does an article that says COBOL may not be so bad really attract a lot of eyeballs for ads?
I say this because the article is bullshit on a tortilla. They talk about how much bugs cost and how many people found, but how does that truly compare to 10, 20 even 30 years ago? They had a source, why didn't they put that in?
No software is perfect. I'm even willing to agree that complexity has increased while quality has decreased, but by how much? The problem is you can't make these assertions without proper comparative facts, including adjustments for inflation.
Finally, COBOL is COBOL. Programs designed in COBOL are, on average, less complex than today's programs. They require more resources to develop, which means more manpower or more time. Also can COBOL be integrated with a front end website? Generate PDFs on demand? Perform EDI? Have sophisticated tools to make integration with newer languages and systems easier? Can you build it as an app on top of a relational or OO database?
COBOL was sufficient for it's time to do what it needed to do. It may be sufficient for many processes now. But COBOL isn't going to magically come back and everyone's going to start creating sophisticated ERPs from scratch with it. It's just another tool.
Re:No Thanks (Score:4, Insightful)
Does that make it better?
Dodgy Management = Bad Code (Score:1, Insightful)
COBOL allows one to produce unmaintainable "spaghetti" code quickly and on a whim - or tight deadlindes - or deadhead despotic management overseers - or....
Then, when the next Yr2K or serious paradigm/technology shift arrives - and the code pool has to be rewhacked to include graphic screens, internet, InterOrbital RFID NeurAINet or whatever, etc.
"Industry" will wail and moan, wring their hands, and cast dire forecasts. And gobble up atrocious consultation fees partly paid by governmental incentives dished out in a panic to avoid impending shareholder-doom.
More modern coding bases, object more readily to simple, old fashioned, "bad" code. Management in general too stupid and harried to administer good coding (including foresight and planning for exceptions and updates) gets what it "motivates" for.
And coding-automation seems to be the sensible direction. Plus collaborative validation. That's usually too much trouble for whatever executive-ishy modism harried underlings are supposed to be whipped into producing constantly revised contradictory results for.
I hope that bringing back a heavily-patchworked bad-code engine - because admin can't produce, verify or manage decent code - is really just the silly joke it really should be.
Re:I don't get it (Score:5, Insightful)
It's actually no different than trying to decipher some code writen in a language you are already an expert in. I'm fluent in both PL/SQL and T-SQL and sometimes I look at a procedure and just have to rewrite it from scratch because the original author wrote horrid code. Sometimes I look at it and can trace through it to figure out what it does, crappy or not. Sometimes it's beautiful and pristine and easy to understand. In the end, I have to make a change to it and I figure out how to change it without breaking anything. Then I move on to something else.
If it were COBOL, I might have a slight hurdle learning the syntax, but already knowing how to code and knowing several languages (BASIC, FORTRAN, C, C++, C#, Java, PL/SQL, T-SQL, etc.) means that a loop is a loop whether it's a FOR i=1 to 15 type loop or a for(int i=1; i [lt] 15; i++) type loop. Syntax can be deciphered with a reference manual. Programming and understanding code is a skill.
Layne
Counterpoint: Bah (Score:3, Insightful)
I love COBOL. I have programmed in many languages throughout the years but I can do my best work in COBOL. I recently started working on it again after a 10 year hiatus and was amazed at the advances in the language.
The thing that you don't understand is that unless your college did not keep up with the compilers that were deployed, that COBOL is not "60's tech" any more. Yeah, it has its idiosyncracies but so do any other 3rd generation languages.
Re:I don't get it (Score:5, Insightful)
You haven't ever needed to learn it, or, logically, ever support anything that was written in it, but you don't see why it's a big deal?
It's a big deal. Legacy COBOL is almost ALL scary code. It's not like it was sexy and clean and professional...The way they wrote that stuff is alien to modern methods. They told the COBOL person what the code needed to do, and he disappeared for a while, and came back and told them it was done. Documentation? Slim. Comments? You must be joking.
I've maintained COBOL code at three significant corporations, and there is so much "hero" code in there, it's hard to even convey to people. This 100,000 line application? It was written by one person, and no one who worked with him was capable of understanding it. No oversight, no review. When he kicked over dead it became a dark spot on the map labeled, "Here be dragons" and no one has touched it since.
Modern methods just don't work like that. In the old days, when you licensed a COBOL app from some company, they sent you the goddamn source code with it, and you could change it...Then the guy who made the changes left, and what is left behind is not supportable by the original company (and the company isn't the original company, but a company that has been bought by a company that was later bought by a different company).
So you need to bring people in, and you need to teach them this application which no one understands, and which isn't really documented, and which is written in a basically dead language, and is often written using the sort of spaghetti code methods we are all told over and over and over NOT TO EVER USE.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Insightful)
What a bunch of horse shit. Don't blame poorly designed code on the language. I wrote plenty of COBOL code in the 80s that was able to recover from failures, even those that wrote into ISAM files. It's not about the code, it's about how clever and imaginative the coder is.
Is COBOL suited for everything?? Of course not, nothing is. That is why a good coder will have several tools and be able to use the one that best suits the task at hands. Creating fixed-output reports?? COBOL. Writing applications to process HTML?? I don't think so.
As someone who currently spends his career rewriting 'legacy' code, whether it be COBOL or C or C++ (10 years ago is still legacy in some minds), I can tell you that rewriting a complete system is a recipe for disaster. First, all maintenance on the new system has to stop. Secondly, someone has to go through every program LINE BY LINE and document what they all do, I can guarantee that what people think they do is not what they really do.
Then you have two choices ... rewrite, or re-engineer. Rewriting many times ends up with the same garbage that ran before, just in another language. Re-engineering is better, but takes longer and is more difficult to parallel test.
My preferred method is to take subsets and gently migrate. 10 small projects with a one or two failures is much better than one large project with one failure.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Insightful)
I've rarely ever seen good COBOL, so maybe it's possible. From what I HAVE seen, especially with the never-to-be-sufficiently-cursed KSAM flat table POS wannabe database files, suggests to me that good, recoverable, code, is nearly impossible to write. None of that stuff is transaction safe. The programs work in too many discrete steps; if it fails, it hardly ever fails in such a way that you can just RE-run the program; either you need a recovery-specific subset or you have to traverse the program until the point of failure and see if you can recover it.
The line by line approach is a recipe for disaster. In old code, especially in old code, most lines are suspect. What is dependent on system crap (ISAM/KSAM files are a good example) that doesn't apply in the modern world? What is part of an ugly kludge? What is just unnecessary?
You need to step back, analyze the process, and replicate the functionality, not the code.
Yes, it's a sucky process. Yes, there are going to be problems. But it's only going to get worse going down the line, and supporting COBOL is getting more nightmarish by the year as there are fewer and fewer people in the market who are capable.
It's going to have to be done. I'm not against an incremental approach, but I am strongly against just pretending like the current situation can continue forever.
Just translate COBOL to C++. (Score:3, Insightful)
crusty old bugs (Score:1, Insightful)
No, IMHO the older systems have been for the most part DEBUGED. An old COBOL system has thousands and thousands of hours of debug, and every modification usually includes some other bug found and fixed. Thats the reason these systems are "comfortable". They work.
Re:KISS (Score:4, Insightful)
First you say:
Keep IT Simple Stupid.
Then you say:
When I build a system from scratch, it is fast, clean efficient.
Which makes me suspicious. Simple and efficient rarely go hand in hand. My first implementation is usually slow and stupid and simple, because stupid (=slow) is generally simplest.
On another point entirely, you say:
It has everything one of the user "needs" to do their job.
and:
Feature creep is a real problem,
The trouble is that COBOL is generally used for financial apps. They never do everything the user needs, because the apps are meant to last forever. Everything the user needs lasts about a year until the legislation changes, or organisational structure changes or various other things. These programs have to feature creep because features keep creeping in from the outside. You can't write a complete, finished financial program.
Generally as programs are incrementally modified, they get nastier as the original program was designed with a certain structure and dataflow in mind. Sooner or later, a new feature comes along which requires a modified dataflow, and that can be nasty to add. So, maybe a little global variable gets added to allow this data to be passed around. To do it "properly" would require a considerable redesign which may not be fesiable. Remember, these programs have to reflect the world right now, so features must be added in a timely manner.
Repeat that process for 40 years where multiple language standards have been ratified, programming styles have come and gone, the original developers are long dead and the employment structure and tax law is completely different and you have a real mess.
But that's not just complexity for the sake of it, and no amount of KISS will solve that problem.
The real problem of Cobol (Score:3, Insightful)
The real issue of Cobol is not Cobol in and of itself but that so many other ideas are used which are not currently in fashion.
Operating provided data structures
Tables with multiple types of data
ISAM/VSAM rather than databases
job control cards with values need for the programs to run
etc....
That will make the environment highly unfamiliar to younger programmers. The IT management has been very irresponsible in creating a situation where code crucial to most companies is undocumented and uses concepts which are difficult for new programmers to understand. Heck most companies did excellent work for the Y2K crisis in documenting their systems which they have lost and not maintained over the last decade.