The last time that COBOL (that's COmmon Business Oriented Language, a 1950's era mainframe programming language) got this much press was just prior to Y2K, when the effort to purge legacy code of two-digit data references convinced many business leaders of the need to re-code all their applications still running in that language. The relative paucity of programmers familiar with the language coupled with the late realization of the problem made the situation much more difficult than many businesses were prepared for, and the impetus to replace the code with more modern programs became a higher priority.

But despite that resolution, it turns out that COBOL is still alive and well in a surprising number of enterprises. And that may be a good thing, according to Neil McAllister's analysis of California's problems modifying the state payroll system in accordance with the governor's plan to introduce temporary pay cuts to state workers to allay the budget crisis there.

The problem, according to state controller John Chiang, is that the legacy COBOL software simply won't allow the automated introduction of those cuts, and that modifying the code so that it will could take up to six months (and another 10 months to reverse later... although to me that doesn't sound like an actual code fix, which should need "reversed" but we'll take him at his word). A more modern system, already planned for, might allow this sort of adjustment more easily... but according to McAllister's calculations, it may not be worth it; nor may many similar "modernization" projects in both government and enterprise.

Citing a recent IDC study on the costs of coding, McAllister determined that the cost of fixing the inevitable bugs in the new system might easily double the original cost of development. Also according to the study, the problem is not so much that the legacy applications have become complex and unwieldy over time, but instead that the newer technologies in which they would be coded have themselves become more complex. In other words, it may be cheaper to keep fixing legacy COBOL than implementing newer, more modern code to replace it.

This shouldn't be as counter-intuitive as it seems. While the term "code maintenance" has been en vogue it's something of a misnomer. Code doesn't need to be lubed or have the oiled changed every 20,000 clock cycles. It's just logic, and it either works or it doesn't. If you need to change the logic, that's just poor planning or new coding, not "maintenance." Indeed, some programmers will tell you that all coding is maintenance is coding... which is the same as saying that none is. The term may be useful among coders, but it simply confuses But the point is that new coding in older languages may be more cost-effective in many cases, and that enterprise planning abilities haven't improved much or at all over time; any new system is just as likely to have long-term issues revolving around the failure to anticipate logic problems.

Something that neither IDC nor McAllister address, however, are the options that businesses have for managing and implementing software projects aside from the traditional and presumptive waterfall development model. While the increasingly complexity of software may be driving up development costs, it seems to me that the conception of agile development and management methodologies is a direct response to those issues, designed to reduce the complexity where possible and increase the predictability in any event. Perhaps it isn't any surprise that mega-projects have become even less predictable and more expensive as technology advances. Maybe the problem is not the new technology, but the implementation methods which haven't been upgraded along with it.

Nonetheless, assuming that newer means better, in technology as in other fields, isn't necessarily a winning strategy for your budget. COBOL, among other older technologies, is hardly dead. To my surprise, there is a COBOL 2002 specification out now. The language may not be widely taught in schools anymore, but there are clearly a group of programmers who are still using it and making a healthy living doing so. And whatever rates they may command, you may still be better off paying them than trying to replace the ancient systems wholesale.