Louis Proyect: The Unrepentant Marxist

July 22, 2015

Once again on the IT challenges in converting to the drachma

Filed under: computers,Greece — louisproyect @ 6:48 pm

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:

  1. 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.
  2. 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.
  3. 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.

10 Comments »

  1. Louis, My career was quite similar to yours, with the possible exception that my involvement in Y2K was developing standardized subroutines for handling the date conversions for large customers. The resultant code was complex to develop, but straightforward for a customer to implement. But I totally agree with your analysis of the IT quagmire. In fact it is probably worse. Many legacy systems are so old that the original developers have almost certainly retired or moved on. Also, most of these aging systems have code that overlays the original function; to convert batch systems to online, convert 3270 input to some hacked up client/server code or HTML or Javascript or Java or whatever the web flavor of the month language is.

    On the other hand, IT systems problems should not be used as an excuse to oppose progressive change. The massive IT job needed to implement Obamacare was a disaster. In Oregon we had to throw away the entire implementation done by a vendor. The federal rollout was a classic case of adding requirements without changing the schedule. It took months to correct the worst errors. The howls from the right wing noise machine demanding a reversion to the old system and was used as an example of why a national healthcare insurance system was impossible. Of course Obamacare should have been a single payer Medicare for all system, but I suspect the initial IT rollout would have been “challenging” in any case.

    Imagine the IT work required to provide a basic income for all adults, for national rent control, etc. etc. Of course it will be a massive IT project and most massive IT projects always take longer and don’t work well in their initial release. What I don’t expect from a Marxist IT guy is a critique of the IT issues used as a reason to fail to move society forward. Perhaps I misunderstood your article, since I know that your contribution to the Nicaragua revolution involved using your IT skills to help the FSLN.

    Comment by Mike Schlosser — July 23, 2015 @ 12:35 am

  2. I am literally the only person who has written anything about these problems. It needed to be pointed out and nobody else had any interest or the background to do so. Converting to a drachma is probably one of the least important things to fix Greece’s problems. As it has become something of a panacea, I saw the need to focus in on it. So that’s that.

    Comment by louisproyect — July 23, 2015 @ 12:55 am

  3. “But the left does not look good by minimizing the technical challenges.”

    Isn’t the same true of socialism? Implementing a planned economy poses probably bigger technical challenges than switching from euro to drachma, but practically everybody who supports socialism talks about it only in terms of politics (“workers’ power”, “direct democracy” etc.) or philosophy (“ending the alienation of labour”, “from each according to their ability”, “free union of free producers” etc.), as if the whole affair didn’t have any technical side to it, or if it did, at least it would be trivial to solve with “the creative powers of the workers” and soon-to-come “communist abundance”.

    Comment by Joonas Laine — July 23, 2015 @ 5:54 am

  4. I am also from an IT background and every single system that I designed came with detailed design documentation, peer review processes etc.

    Dates are probably the number one key dimension. I would be surprised if they were left in a such a state as to be undecipherable.

    I accept there would be IT difficulties but you are overplaying them.

    Comment by Simon Provertier — July 23, 2015 @ 10:21 am

  5. Joonas, you are quite right. Socialism is difficult to implement. I observed this first-hand as president of the board of Tecnica that sent hundreds of programmers to work in Nicaragua in the 1980s, including me. As I said in a previous post, Lenin thought that unless the USSR was rescued by triumphant revolutions in advanced industrial countries in western Europe, it was doomed. Does that mean he was expressing TINA? If the USSR faced such huge obstacles, what does that mean for peripheral societies like Nicaragua and Greece?

    Comment by louisproyect — July 23, 2015 @ 12:07 pm

  6. “Implementing a planned economy poses probably bigger technical challenges…”

    Please look up spontaneous order!

    “Lenin thought that unless the USSR was rescued by triumphant revolutions in advanced industrial countries in western Europe, it was doomed”

    What was it about those ‘advanced’ societies that allowed these technical difficulties to be overcome more easily? After all Britain had to go through an IT revolution also!

    Comment by Simon Provertier — July 23, 2015 @ 12:31 pm

  7. Not sure if you know him, but New School Economics Professor Sanjay Reddy had a recent post on the same subject: http://reddytoread.com/2015/07/12/greece-a-possible-tactic-for-reintroduction-of-the-drachma/#more-150

    Comment by Charles Dolph — July 24, 2015 @ 5:00 am

  8. “Mr Varoufakis recruited a technology specialist from Columbia University to help handle the logistics. Faced with a wall of obstacles, the expert broke into the software systems of the tax office – then under the control of the EU-IMF ‘Troika’ – in order to obtain the reserve accounts and file numbers of every taxpayer. “We decided to hack into my ministry’s own software programme,” he said. ”

    mmmm, Columbia ??? 🙂

    Comment by jeff — July 26, 2015 @ 7:01 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: