By Louis Proyect, who has written for Sozialismus (Germany), Science and Society, New Politics, Journal of the History of Economic Thought, Organization and Environment, Cultural Logic, Dark Night Field Notes, Revolutionary History (Great Britain), New Interventions (Great Britain), Canadian Dimension, Revolution Magazine (New Zealand), Swans and Green Left Weekly (Australia). Originally published at Louis Proyect: The Unrepentant Marxist
On July 14th 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:
- 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.
- 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.
- 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:
- 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.
- 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)
- 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.
- 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.
Comments are enabled at the request of the author