Slashdot

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.

Coming from someone who is currently supporting a legacy COBOL system, you're right on target.

COBOL is shit. Most legacy COBOL code is not designed with anything like what we'd consider "best practices" today. The language itself is unfriendly, and doesn't lend itself to the modern world.

What it does have is inertia. It works, right? Why replace it? It's the product of decades of business evolution, do you think you can replace that overnight? New code will never be as good.

Basically, they're comfortable with their crusty old bugs, and they don't want to deal with scary new bugs.

In my environment we've basically thrown this whole interface built on Oracle and Java on TOP of the old COBOL MPE/ix system. Placates the conservative financial types, while providing some modern functionality.

Still there are all kinds of problems with the old systems. You can end up with some really scary problems with old code, because it doesn't recover from failure like you'd expect modern code to. A java billing application running on a modern transactional database...If it crashes, you can just run it again. A COBOL app on a legacy database? That just ruined your day.

I would hope that the response to the situation would be to finally migrate your systems, not to accrete more levels of unsupportable crap by dragging COBOL programmers out of retirement, or forcing existing programmers into that outdated mold. I know the money types though; they are perfectly capable of trying to stick with the outdated method simply because it's in their comfort zone.

Yup, no doubt the people that implemented this system were complete idiots, unable to come up a system that was 'well designed'. Oh wait, I wonder what 'good design' was when this was written. Maybe it included things such as 'being able to run in a machine with 16MB virtual address space, with 1MB real memory installed'.

As for security, you're probably also right there. It seems just about every week I read a report of some COBOL-based payroll system being hacked (which you would expect, since there are probably thousands of such installations). Oh wait, I never read that.

It seems to me you are quick to criticize, without even a basic understanding of the requirements for this change. It is NOT some simple 'raise minimum wage'. It is 'temporarily lower ALL employees wages (hourly and salaried) to minimum wage'. When the budget is passed, put the wages back where they were and issue back pay. Don't forget about little details like deductions for taxes, insurance, retirement, etc. How do you calculate the withholding rate for income tax? What do you do when someones deductions exceed their pay? When the pay is restored, what do you do about people that have left, retired, or died in the meantime?

I think that the timeframe they give is not all that unreasonable, considering all that must be done. It will take a substantial amount of time just to come up with complete requirements. Then the coding must be done. Since this is a financial application I am sure there is much testing, and probably some fairly stringent auditing that must also occur.

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=

In my case, I've taught myself to use a couple of dozen programming languages over the years, and I've mastered several of them. However, I've never managed to make it all the way through the senseless boilerplate headers of any COBOL program before puking. Once the monitor is covered with puke, it's too hard to see the screen well enough to continue.

I'm a full-time COBOL programmer with a history in Java professionally and C/C++ and a number of other languages in my own company.

COBOL isn't hard to learn. It certainly isn't much more difficult than any other modern language.

The hard part is that COBOL really doesn't help you much. In most modern languages you can just grab a library containing a complete linked list or efficient sort algorithm. COBOL programmers actually need to know how stuff like this works. Now maybe you're an exception, but surprisingly many Java developers don't know the first thing about basic algorithms and memory structures like that. Add to that the need for high performance (the cost of running a COBOL program is often charged by the minute and measured in fractions of seconds), high stability (I've worked with code which could bankrupt a company if not fixed within a week or so) and the complexity of the typical Mainframe environments COBOL runs on, and you can see why it isn't trivial to start working with COBOL.

The language is easy, using it is not.

Like was mentioned in a previous reply, it's not JUST learning COBOL, there is also other stuff like CICS, that you have to know as well.

But you take something else like C. I can get gcc, and start writing code. Same thing if I want to do some web 2.0 project. It's almost trivial to get a LAMP setup up and running.

There's nothing that can simulate a working z/OS environment. There's no compilers to download. There's an emulator out there called Hercules for various IBM mainframes, but you can't get the OS to run on top of it. It's near impossible to go grab "COBOL for Dummies", and start firing up code. COBOL is also rarely taught in university anymore. So the only place you COULD get some exposure to the system, you aren't going to get it. Even if you COULD download the OS, setting it up is very nontrivial. And it's NOTHING like you've seen before.

And these systems aren't just 100% COBOL either. There's a host of mainframe type things like Natural for an ADABAS Database that you're NEVER have experience doing unless you already have a job doing it. You got to the point to where you wrote that program in COBOL, now do you know the JCL to set it up to run? Ok it ran, know what a SOC-7 error is? BTW, it's an uninitialized numeric to save you from typing it into Google.

All these things mean the vast majority of people out there now just don't have ANY experience in dealing with these things. It's hard enough to find people that can step into a team to support a major project. Add in those legacy requirements, and it's probably nil. Anyone qualified to do it, is probably 3 years from retirement from where they are at, and would probably have to offer 7 figures a year to make it worth their while to screw up their retirement options.

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.

COBOL is EASY compared to C/C++ or even Java/C#.

That's a strength, not a weakness.

You mean like Cobol on Cogs [coboloncogs.org]? :)

First you need an Object-Oriented COBOL, aka ADD 1 TO COBOL GIVING COBOL.

You are right, COBOL probably does need a new hip.

My old 2 year school still teaches COBOL, RPG, and AIX classes (Southwest Tennessee Community College) and even offers a 2 year A.S. degree in those technologies. The University of Memphis used to teach COBOL in the MIS track, but I have a feeling they've jumped on the .NET bandwagon. I can't speak for the rest of the country, but Memphis, TN has a lot of legacy mainframes and one of my former employer still churns out around 10k lines of new COBOL code a year, at minimum.

What a lot of folks also don't realize is, you don't just rip out a multi-million dollar mainframe system and just replace it with something new. It's also not as simple as "just coding it in Java" and deploying on that hardware. Hell, even writing it in C has issues on many of these machines. The mainframe I was exposed to didn't support the full ASCII character set and you had to use trigraphs. You can't just "apt-get compiler-for-language-of-choice" on these machines, nor download a .msi and get an instant installer.

These are mainframes. They don't even have a filesystem that you would recognize, much less a bash prompt. JCL anyone?

The point is, it's not a simple matter of just porting the software into a modern language. You'll also have to build out the entire hardware system, write the software, test extensively, and then run both concurrently to ensure consistency, and all of that costs money. Lots and lots of money. If what you have works for what you need it for, there's no impetus to change until something like this comes along. However, I'd be willing to bet it's easier and cheaper to change *policy* (the laws) than to scrap the old system completely and rebuild it from scratch.

DeVry does, or at least did, a few years ago. I should know, I took the class. It was an upper level course, and part of a set of required electives. You had to take COBOL or (something) or (something). I don't even remember if the other two were languages or theory or what. But it was there. All campuses don't have to teach it, it is market driven. Having a very large and old telephone company not to far away means there is some demand for people who have had some exposure to the language.

As some others here have commented, COBOL is amazing. I learned programing through BASIC, HyperScript, C, Java, and other languages. COBOL is so primitive in so many ways. It feels a bit like trying to use your knowledge of Romance languages to decipher how to say something in Japanese.

Now this makes sense, as COBOL was designed so long ago for machines that only had punch-cards and such. But for most any student who learns programing these days to be given COBOL is going to be a huge logical shift.

And that doesn't include the syntax. Ignoring the special columns and such, no modern languages are very close to COBOL's syntax.

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.

Not hardly. I just rewrote a VB 3-6 application into C#.NET because nobody can compile it anymore (requires a 16-bit tab component and nobody has VB4 16-bit install disks, let alone floppy drives even if we did).

The original application was 13,000 lines of BASIC, written (mostly full or half time) over the span of 11 years. The new C# application is 900 lines and has MORE functionality (not to mention nice commenting as opposed to NONE) and I wrote it in 2 months.*

Return to the bad old days of underpowered languages that require thousands of lines to read a database and display it on the screen? No thanks.

*BTW, this brings up a good point. Just because some company has 9 million lines of COBOL doesn't mean that the programs couldn't be replaced with 500,000 lines of an OO language.

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.