Friday, December 03, 2010

A Programmer’s View of the Limping Euro:

When people argue against Daylight Savings Time, they rarely consider the incredible number of computer programs, operating systems and intelligent products that will be wrong if any time change is instituted. Revising the calendar (as many have proposed), so that every year would use exactly the same universal calendar, would require revisions to a ton of date-savvy computer programs, to make them calculate dates correctly. Now what will happen in the banking industry if some European countries, that are desperately hurting, go off the Euro?

In 1998 I studied the software systems that banks and financial institutions used for their rich customers. At that time, the Euro was coming in like an express train, and most of these companies were preparing to support it. The transition to the Euro posed special problems, such as the need to state customer wealth in multiple currency bases, and the simple fact that the Euro was not linked to a single country.

I talked to one owner of a Swiss Bank who told me frankly that the Euro was years away. He saw no point in preparing his bank, or his software, to support it. I suspect his bank suffered greatly when the Euro arrived on schedule. The point is, banking software has to be prepared in advance to avoid hiccups if one or more countries go off the Euro. And unlike the process of shifting to the Euro, which was documented and specified years in advance, there’s no official planning going on. Many programmers may be facing a lot of 24-hour shifts in the near future!

Here’s a trivial example of what I’m talking about. In 1986, Israel brought out the New Shekel, worth 1,000 of the old Shekel. Everyone knew that Israel was going to replace the old Shekel with a more useful unit of money, but it was a closely guarded secret whether the exchange would be 100 to 1 or 1,000 to 1. After the new coin was announced, I talked to an Israeli Cobol programmer who had been revising his banking software to work with the New Shekel. In Cobol, you lay out the way a report will look by providing coded “pictures” of the dollar-and-cents fields. The appropriate numbers of decimal places that these fields needed would differ, depending on the New Shekel’s value. This programmer was gleeful, because he had laid out all his money “pictures” assuming the 1,000 to 1 conversion. If he had guessed wrong, he would have had to comb through his code to make many manual changes. And that’s a very small concern compared to an actual currency change.

No comments: