Apparently my brief reference to Australian economics professor emeritus Bill Mitchell’s failure to mention the IT aspects of Grexit in a Naked Capitalism article touched a nerve. In a 3500 word article that appeared on his blog on Friday, July 24th he minimized the challenges and appealed to his own authority as an IT professional to drive his case home. He also took up some points in my article that weren’t really directed at him, particularly my brief remarks around the question of a Grexit not being sufficient to bring an end to austerity.

I did not have Dr. Mitchell in mind when I made that point. Furthermore, I don’t think that there is that much difference between us on the economic questions but as I will now point out we are still far apart on the IT implications of a Grexit that I will now explain.

To start with, he groups me with the sensationalistic media reports on Y2K that warned about Armageddon as if I or any other seasoned professional really worried about such an outcome. He also alludes to the opportunistic sales pitches from consulting companies anxious to get their foot in the door to help firms large and small avoid a Y2K catastrophe but at a steep price. If you were part of the permanent staff in any large organization like Columbia University, you had a very clear idea about how to do a Y2K conversion without tears.

Furthermore, I am quite sure that given sufficient time, funding and personnel, the conversion to the drachma is feasible. But the purpose of my article was not to argue that it was impossible. It was only to alert a lay audience what kind of challenge it represented. For those who have not managed large-scale project implementations, it was easy to imagine that such a conversion could take place in something like a few months. But I am convinced that it would probably take no less than three years based on my 44 year experience managing, designing, programming and testing mission-critical applications in a variety of banks, brokerage houses, and insurance companies. That was about what it took to go from national currencies to the euro and I would expect that it would take about the same amount of time to reverse engineer the process.

Perhaps nothing captures Dr. Mitchell’s unfamiliarity with the IT challenges facing a euro-to-drachma conversion than what he has to say about Y2K:

As the Naked Capitalism author notes it was really about software that had used two numbers to designate the year (MMDDYY) instead of four (MMDDYYYY). Several straightforward computer changes were made to resolve the possible problems depending on the situation (date expansion, date re-partitioning in overfull databases, windowing patches etc). Very trivial.

I did a double-take when I read this. Very trivial? Well, it is very trivial to expand the year from two digits to four digits but that was never the challenge. In fact Dr. Mitchell completely ignored what I wrote, namely that the task of finding the code was like looking for a needle in haystack. At Columbia University we divided up thousands of programs and assigned programmers to search through thousands of lines within each program to track down a six-digit date and convert it to eight digits. It took 10 seconds to modify each date when it was found but it took the better part of a year to find them all. To repeat, a search for any field of data that had “date” in its name was straightforward but what if a programmer labeled it “dt” or even “d”? Furthermore, what if a piece of data identified as “admission_date” is moved into a temporary field called “admission_temp”? You have to track the movement of data within the entire program to be sure that you had all bases covered. This was a laborious task that took us the better part of a year. It also took another year for IT to test all of the modified programs to make sure that the integrity of the data was preserved.

Greece would run into the same challenges in a euro to drachma conversion but likely would not have the kind of infrastructure that a well-endowed Ivy university was able to rely on. Given the economic desperation and chaotic conditions that Greek firms large and small operate within, it is a serious mistake to use one’s influence to persuade policy-makers to leap without looking first.

Continuing in his best case scenario vein, Dr. Mitchell dismisses the possibility that hard-coded values in a program constitute a major hurdle:

The issue is simple. Rules for determining eligibility for a service (mortgage etc) might have thresholds hard-coded into the computer system. So if your bank balance is above 1000 you qualify for a loan. Good programming clearly creates variable definitions (say, $threshold = 1000) in easy to find and edit part of the system and then uses symbolic references ($threshold) throughout the rest of the system so that when the threshold might require alteration there is one data entry required which feed the old system.

Yes, we are all for “good programming” but my experience over the years is that there is enough space between “good programming” and the actual code in legacy systems to steer an ocean liner through. In the ideal world, a hard-coded value is never used. For example, as Dr. Mitchell points out, 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. In fact, Mitchell expresses a surprising degree of naiveté when he writes:

So if there is a lot of ‘hard-coding’ in the Greek financial and business systems it would require some work. The reference the Naked Capitalism article uses was written in 1999 and relevant to rather dated practices and the big challenge of converting all the currencies into the euro and all the different national business systems into an integrated set of systems that could cope with the common currency.

I would suspect the assessment that there is a lot of ‘hard-coding’ now would be amiss. Business systems have become much more sophisticated and homogenised in the 16 years since that article was written.

But the point is that when Greece went from the drachma to the euro in 2002, it was practically preordained that the modifications would be made to existing software that might have been written in the 1980s or earlier. Why would Greek banks have written an entirely new Direct Demand Accounting system in that period? Yes, business systems have become more sophisticated since the year 2000 but you can be assured that those that serve the mission-critical needs of Greek banks are decades old.

I should add that although I worked on mainframes for 23 years, the last 21 were spent at Columbia in leading edge technologies of the sort that he describes as “sophisticated” and “homogenized”. When I was hired by Columbia University in 1991, it was to make recommendations about exactly such technologies in my capacity as Development Technology Coordinator. Later on, once such technologies were adopted, I had over 15 years experience designing and programming financial applications in Java using the Struts framework. Additionally, I supported that application’s Sybase backend using Perl and other Unix-based tools. Finally, part of my retirement contract involved being available on a contingency basis for technical support as the need arose. Even now I stay in touch with my colleagues to give them my take on future IT directions.

Dr. Mitchell also seems to have missed the point I was making about historical data:

These include the historical presentation of records, for example, bank statements. These problems were already encountered and solved in the transition to the euro. There is no reason to suspect that any new issues have arisen. The Bank of Greece knows how to do this and could easily issue a procedural manual to the commercial banks and other financial institutions.

But my point was that ad hoc software would have to be developed to modify historical data. For example, just to repeat myself, if the United States elected a Marxist president and adopted a new currency called the Rosa that was pegged 10 Rosas to the dollar, you would have to develop software that went through the databases to multiply all occurrences of each cash-based data store by 10. (Let’s hope we’ll see that someday.)

Finally, if I understand Mitchell correctly, he seems to be saying that you could dust off the pre-euro conversion software from 1999 or so and use it to replace current-day systems. That would be fine if there had been no modifications made in the past 16 years to incorporate new business rules. But as we know financial applications are highly dynamic since the industry is always sensitive to opportunities that can always boost corporate profits to the disadvantage of the poor customer. Who knows? Maybe when the entire world converts to the Rosa, or even when money is no longer necessary, we will not have to face such problems but in the meantime reality must govern all major policy decisions, including ones that revolve around information technology—the nervous system of any modern economy.

On July 14^th I wrote an article titled “Convert to the drachma–piece of cake. Right…” that was a first take on the difficulties in implementing a Grexit from an IT standpoint. Since then I have tracked down a number of high-level strategic planning documents written in the late 90s that give me a much better handle on what those difficulties amount to. Except for the folks at Naked Capitalism who reposted my original article, there are very few people on the left who have any inkling of the problem. One of them is Robert Urie who alluded to it in a recent CounterPunch article:

A central difference between Argentina and Greece is that ‘all’ that Argentina had to do was to break the peg (fixed currency exchange ratio) with the USD while implementation of the Euro was a massive technological undertaking that replaced the Greek technology and institutions that supported the drachma. In the event of a forced Greek exit recovery of these technologies and institutions would take time that the Greeks don’t have. Breakdown of the supply-chain— the integrated economic relations that together facilitate economic production, causes a cascade effect where once lost, has to be rebuilt from the ground up.

Instead what I have mainly heard is that it is much more of a piece of cake than my article would suggest. For example, Canadian leftist Ken Hanley, who wrote an article titled “The German Grexit plan may have been the lesser of two evils”, commented: “The creditors were able to develop a Grexit plan. Schaeuble even presented a Grexit plan as an alternative to deal and many think that his whole plan was to force a Grexit.” He also referred me to an article by an Australian economist that assured his readers “A Greek exit is not rocket science”. Well, it might not be rocket science but computer science is certainly relevant notwithstanding the economist’s failure to refer to IT once in his article.

The same shortcoming exists in an article that has been embraced by many on the left as a recipe for overcoming austerity. Titled “Greece: Alternatives and Exiting the Eurozone” and written by Eric Toussaint, who works with the Committee to Abolish Third World Debt, it makes very useful recommendations but once again neglects to mention anything about IT.

Now my point in referring to these difficulties was never to support staying in the Eurozone. It was primarily intended to alert the left about the dangers of thinking in terms of short-term solutions. Furthermore, my own position is that Greece’s difficulties have more to do with the underlying economy rather than what currency it uses. Some Marxists, who have been sharply critical of Tsipras, appear to understand what this means. For example, In Defense of Marxism, warned:

Some people have argued that if Greece is pushed out of the Euro this could eventually provide a solution to its economic problems. That is naïve in the extreme, not to say irresponsible. The question would still remain: what kind of an economy, run by whom and on the interests of whom?

Let us assume that the new currency is called the drachma. What will happen to it? It will fall like a stone because nobody will want to hold it. That will cause prices to rise steeply, even hyper-inflation, as in Germany in 1923. People’s savings will be wiped out. There will be a deep slump and even more unemployment.

Moreover, if Greece is forced out of the Euro, it will also find itself out of the European Union. The European bourgeois will not want to see its markets invaded by Greek goods made cheaper by the inevitable fall of the drachma (or whatever other currency is chosen). It will be necessary to take very drastic measures in order to avoid an economic catastrophe. Half measures will be useless. One cannot cure cancer with an aspirin.

I also thought that the Belgian Trotskyists of the LCR-SAP had good advice:

6. Leaving the Euro is not a sufficient condition to break with austerity (as the case of Britain proves) but, in the Greek case, for the countries of the periphery and those which are not in the heart of the euro zone, it is clearly a requirement.
7. The need to break with the euro does not imply making leaving the euro the central axis of an alternative programme. Even in Greece, where the question arises in a burning and immediate way, the axis of the alternative programme must be the rejection of any austerity and the implementation of social, ecological, anticapitalist and democratic policies, which directly improve the fate of workers, young people, women, the victims of racism, and the peasants.
8. To make leaving the euro the axis of the alternative would be to run up unnecessarily against the very generally-held idea that the currency is only “neutral” technical means of allowing trade, whereas it is in fact also the crystallization of a social relationship. To make leaving the euro (or the EU) the axis of the battle would be also to play the game of the hard-line and far right, by spreading the illusion that a harmonious socio-economic-ecological development would be possible within the national framework. This illusion harms internationalist solidarity. However, this is crucial not only for the fight in Greece, but also because the integration of the economies on the continent requires a European anticapitalist perspective to satisfy social needs and to answer the urgent ecological needs.

Before moving on to the technical aspects of a Grexit, I should say a few words about my background. Even though my regular readers know that I worked in IT for 44 years, it might be useful to mention something about my experience.

To start with, before I began working at Columbia University in 1991, most of my work experience was in financial applications. I worked for five different banks: FNB of Boston, Texas Commerce Bank, Irving Trust, United Missouri Bank (where I programmed ATM’s) and Chase Manhattan. I also worked for investment banks: Salomon Brothers and Goldman-Sachs. Finally, in the 21 years I was at Columbia University, most of the time was spent working on the financial system used for purchases, general ledger and the like. Back in 1998, part of my workload over a two year period was to evaluate legacy software to identify changes needed to accommodate the arrival of 2000, a technical challenge that was dwarfed by Eurozone conversion that I will now explain.

The following documents were key to the observations I will be making:

1. Daniel O’Leary, “The Impact of the Euro on Information Systems”, Journal of Information Systems Vol. 13, No. 2, Fall 1999. (https://msbfile03.usc.edu/digitalmeasures/doleary/intellcont/Impact%20of%20Euro-1.pdf). I referred to this in my original article.
2. Pieter Dekker, “Preparing Information Systems for the Euro”, a sixty page white paper prepared for the European Commission on the Eurozone in September 1997. (http://ec.europa.eu/internal_market/accounting/docs/markt-1997-7038/7038_en.pdf)
3. Patrick O’Beirne, “Managing Risk in Euro Currency Conversion”, Cutter IT Journal, 1998 (http://www.sysmod.com/eurorisk.pdf). This is basically a shorter version of the Dekker article above with a useful bibliography referring to other material in this vein.
4. Rainer Gimnich, “Analysis and Conversion Tools for Euro Currency Migration”, Workshop on Software Reengineering, May 1999. (http://www.uni-koblenz.de/~ist/RWS99/beitraege/Gimnich.pdf)

To start with, it would be useful to understand what took place in a Y2K migration. In many programs written in the 60s and 70s, when the year 2000 seemed like a long way off, dates were formatted as MMDDYY. This meant if you were trying to establish whether a bond would mature in five years, you’d subtract something like 07/22/67 from 07/22/72 but when 2000 arrived, how could you determine whether 07/22/04 meant 1904 or 2004? The answer was to wade through millions of lines of code and expand MMDDYY to MMDDYYYY.

In a computer program, every field of data is uniquely named. This means searching in a COBOL program for something like “date_today” is pretty simple. But what if a programmer called it dt_today instead? Of course, you might figure out that “dt” means date but some lazy programmer might have written it as “tdy”.

You will have the same problem, of course, with a euro to drachma conversion. Searching for the Greek equivalent of “amount” or “amt” becomes a drain on any IT staff.

A conversion from a local currency to the euro was a whole order of magnitude more difficult when it comes to converting currency amounts, even when they are identified. For nations such as Spain that did not have a decimal based currency like the euro, the rounding became a challenge. Since this did not apply to the drachma, a simple replacement might be in order and that would be the end of it.

However, the big problem was testing for a hard-coded amount parameter as I tried to explain on Naked Capitalism underneath the crossposting of my original article:

For example, there might be tests to see if a customer has sufficient funds to be qualified for a mortgage. A program might conceivably mark it as eligible if there were 10,000 euros in the account. Switching to a drachma might make everybody eligible–not that there’s anything wrong with that obviously–but you can see that this is not a simple matter. Just being able to handle a drachma instead of a euro does not mean that software is meeting expectations. You have to do a BUSINESS analysis, which is the first stage in any systems implementation.

As it turned out, the Gimnich article listed above makes an identical point:

In many cases, amounts are hard-coded in the application programs. For instance, statements of the kind IF amt_1 < 1000 THEN … appear quite often. Here, the threshold value is simply used as a constant in the program: no symbolic constant, no variable declaration, no external amount table read.

Assuming that Greece’s programmers could convert programs to handle the drachma rather than a euro, this would mean that you could start withdrawing a new currency from an ATM on day one. And at the end of the month, you’ll get a bank statement with amounts designated in the new currency with the proper currency symbol, etc. But that’s just the tip of the iceberg. Any bank maintains a history of transactions for all customers that are used for determining loan eligibility, etc. Your account might have the proper data from the day when the drachma conversion took place going forward but what about the ten years or so of prior transaction history which were denominated in euros? A suite of programs would have to be written to manage the conversion of historical data. This is not a minor task since identifying which files contain such data requires plowing through an enormous IT inventory. Since documentation is always given short shrift in the corporate world, expect major technological hiccups or even heart attacks.

The tasks described above are properly administered in an IT department, which is centrally controlled but that’s not the end of it. Ever since the advent of personal computers, there are huge amounts of mission-critical data that are not maintained by the IT staff. The finance department of any modern corporation is overflowing with PC-based spreadsheets that are used for budgeting, etc. All of these spreadsheets will have to be evaluated for their criticality and converted to the drachma if need be. Once again, a major task.

In August 2001, Computerworld, a trade magazine I read for many years before retiring, described the risks facing small and medium sized businesses that had not gotten up to speed on the euro conversion:

Pollard said the unpreparedness of vendors and suppliers won’t create a catastrophe in the European marketplace, but it will cause supply chain slowdowns and force some small and medium-size businesses to revert to using paper invoices, bound ledgers and filing cabinets.

But Noel Hepworth, head of the euro conversion project at the European Federation of Accountants (FEE), an industry trade group in London, said companies that aren’t ready will quickly be forced out of business by large manufacturers that will refuse to deal with them.

Think about what this would mean for Greece as its businesses tried to do the same thing in reverse. This nation has a huge proportion of smaller firms. It will be exactly those that will be forced out of business if they can’t make the cut. If adopting the drachma will lead to a sharp devaluation as all experts predict, those businesses will be rotten ripe for buying up by foreign investors looking to make a killing.

Now in the long run, it might not matter that all these problems lie in store. It is probably the case that leaving the Eurozone is a necessary first step to escaping the clutches of the German bankers, the IMF and all other predatory institutions. But the left does not look good by minimizing the technical challenges. Most of all, it is worth remembering what Lenin wrote in “State and Revolution”, which is just applicable to a state embarking on an anti-austerity program based on neo-Keynesian principles as it was to the infant USSR:

We are not utopians, we do not “dream” of dispensing at once with all administration, with all subordination. These anarchist dreams, based upon incomprehension of the tasks of the proletarian dictatorship, are totally alien to Marxism, and, as a matter of fact, serve only to postpone the socialist revolution until people are different. No, we want the socialist revolution with people as they are now, with people who cannot dispense with subordination, control, and “foremen and accountants”.

I would only add programmers to the people Lenin identified above.