@wayne tavitt

Isn't that the point?..

Re: Decreasing Salaries?

"The problem isn't simply decreasing salaries; the problem is calculating back pay and taxes on said back pay after reinstating everyone's salary in the future. The code to handle that scenario simply isn't there. Doing it all by hand is obviously not realistic."

Then the system was bad to start with.

I've seen systems, designed in the late 70s and finished in the (very) early 80s (ok, they're not quite 30 years old) that could do things like this without a hickup.They were explicitly designed to do things like that. If an employer finds out, that he'smade a mistake and "underpaid" his employes for the last 3 years would have a serious issue rectifying this problem. A good payroll system will "notice" backdated salary changes, recalculate EVERY payroll cycle (sure it'll take some time to do) and come up with a pay slip that contains all the changes and adjustments, incl. tax, pension payments, health care and whatnot.

I like COBOL

COBOL is a cool language. A bit wordy at times, sure thing, but the wordiness has its advantages too. Look at a completely undocumented piece of C code, somethink like 2K loc, and then look at some COBOL code that does the same thing. Now which of them do you think is easier to understand? Of course it is a pain in the neck to

Most people who bad mouth COBOL base their "criticism" on hearsay and things that have been eliminated since COBOL 85, in some instances even COB 74. The bad reputation of COBOL is almost solely based on the Y2K problem, the reasons for which have been pointed out numerous times here. Guess what, take a look at how many UNIX systems are ready for the "UNIX date" issue? Well? It also stems from a time, where people simply didn't realise their ideas might be used way beyond the "expected" lifecycle. Hey, come on, Windows 95 even crapped out, because there suddenly were CPUs that could do things faster than expected (AMD K2 "issue"). Mistakes were made througout the entire industry and some even after people should have realised they were wrong.

A "nice" annecdote: Back in 1990 or so, we started writing a business application in COBOL. In the very early stages of development, I suggested to my then supervisor, that we make all date fields 8 instead of 6 digits. His answer was: "Y2K is 10 years away. Nobody will use this software by then!". Needless to say, the softwarewas canned by the end of 1999 because it was way too expensive to make it Y2K compliant and all clients using the software were left in the rain. All Y2K was, was shortsight on behalf of those, who should have known better.

You can do (almost) anything in COBOL. IIRC the Micro Focus COBOL compiler was mostly written in COBOL...well, I wouldn't go that far, but a solid business app, I would write in COBOL. Even today. Why? Because COBOL was made for it, because I can't recall buffer overflows in COBOL apps, because they don't crap out. How many of your C, C++, C#, JAVA, VB, Delphi and who knows what programs, will still run in 10, 20, 30 or even 40 years? Well?

All languages have their pros and cons and some are better for certain purposes than others. Would I want banks to run systems written in C? No thanks, not with my money involved. One buffer overflow, all gone!

incomplete info

Setting aside the "replace COBOL" foolishness in this thread, the actual business problem here is much more complicated than the article suggests.

1) There are over 200k employees, which puts the State of California into rare company. Your crappy little payroll system, designed to work for small businesses? Yeah, not going to cut it in the big leagues. (There are fewer than 20 companies on Forbes list with this many or more employees.)

2) This is not a pay cut. Repeat that after me: "this is not a pay cut." This is pay deferrment - the system needs to calculate their pay, but only deliver the equivalent of federal minimum wage, tracking how much of the rest will be backpay after the budget passes.

3) This is not an across-the-board change. Certain categories of employees are exempt, certain categories are receiving no pay at all (appointees, certain types of professionals, etc.). These categories are somewhat arbitrary, and do not currently exist in the payroll system (or anywhere else).

4) The $30M? Not only was there a typo of a few orders of magnitude, but that was not to replace this system, but a 'similar' system. Don't know what it would take to replace the state's payroll system, but, having worked on other large-scale systems, I'm pretty sure that it would be a multi-million dollar system. The complexity of the system reflects the complexity of the state's payroll - thousands of employees, multiple unions, different types of 401k plans, etc.

Talking about how easy you think this would be doesn't make you sound like a 'real programmer' - it makes you sound like a kid with no experience working on large projects.