Continuing the conversation about IT and the Grexit

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.