Grexit requires immense software changes. It took EU 11 years

grexit photo
Photo by quapan

Grexit, with a return to drachma, cannot be done overnight or even within months, especially not for a financially devastated country like Greece that has no extra money. A primary reason is ancient software needs to be studied line-by-line to look for references to euros and then to make sure the code will reflect the new drachmas. This, to non-coders, may seem easy. It’s anything but. References to euros may be hardcoded or difficult to find because the programmer used cryptic variable names.

Worse, if there is data in tables referring to euros, then the data may need to be converted to drachmas. Or not. Maybe it should stay as euros with the new data as drachmas. Then you have to know which currency is being referred to, which makes things even more convoluted. Or you store both values, which would require database structure changes in very old data tables. Greece was able to convert to euros in 2002, along with all the other EU counties. Presumably thousands of coders were helping each other and huge resources were available. Greece has none of that now.

It has been surprising to see how much resistance readers voice to the fact that making large-scale IT changes within major financial firms is extremely time consuming and that most large scale projects fail. That means the difficulty of converting IT systems to incorporate drachma is a major process not just at single institutions, but even more so across complex and fragmented systems like electronic point of sale devices, like credit card terminals, and ATMs. That is why it took eight years of planning and three years of conversion for the introduction of the euro to go smoothly. And the size of the code base and the volume of transactions running over these systems has increased, while most of the legacy code on mainframes from that era remains in place.

As an example:

It is good practice to define an external variable such as $threshold but in practice Cobol programmers (the language of choice in most financial applications) tend to take shortcuts because they are always under the gun to meet a deadline. So instead of defining an external variable that can be modified in a single location, they will test for ‘10000’ or whatever. Since the software in Greek banks is likely to be decades old, I doubt that the “good programming” practices hailed in computer science classes find much reflection within them.

On top of the IT uissues, Greece would also need to find billions to print drachmas.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.