Yves here. 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.
Members of the commentariat also seem unable to grasp how changing this code is very labor intensive. As reader Andrew Williams put it:
What many of you “it’s easy” people fail to understand is that mainframe programming is nothing like today’s coding. COBOL, PL/I etc. do not support modern concepts like objects, polymorphism or anything else. Think assembly language with nicer mnemonics. XML? Hah, there is virtually no such thing for the mainframe. There’s no git, no mercurial etc. Virtually none of the tools that exist for Wintel/Linux are available to mainframers.
In large organizations there are hugely cumbersome change management processes. Where I am, a simple code change might take a minimum of eight weeks to deploy, and we only have a dozen systems. Actual application changes like envisioned here would take at least six to twelve months for coding and testing, and then another four months for deployment. For large banks, I would expect the timeframes to be even longer because the systems are so critical.
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). Jointly published with Louis Proyect: The Unrepentant Marxist
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.
Comments enabled at the request of the author
110 comments
Comments are closed.
i always wonder how some will comment on things they obvious dont know. COBOL (and PL/I) both do object orientation, and they do XML too. course unless you worked with them, you wouldnt know that. its not like they have stood still since they were first created. non of the current platforms dont have a long history, as they all came out of some thing else.
as to how hard would it be to change the systems to wok with a new currency. it depends. did they actually change it when they ‘converted’ to the euro or did they just reuse what they had and have it deal with the euro like it did the drachma? i dont know, does any one? course its not like new currencies dont appear from time to time, so maybe they have this down to a project that you do step1-step99999 and your done. course it all depends on how the applications were written (not what they were written in or what hardware they use. cause you can make any of them a nightmare to change).
For heaven’s sake, the author is talking about COBAL on legacy systems and the commenter, who you are taking issue with as if he was the author of the article, did not write the post. Moreover, given the context, even the commenter is almost certainly talking about legacy systems as well. Linking to such code with a dynamic library of OO enabled COBAL would spell, “fall flat on your face,” even if you could get as far as a method call.
You’re picking at hairs.
COBOL
guess you dont know COBOL either., and the author is a she not as he, no do you know legacy systems either. some of which are relatively new. usually those are the ones that actually work
Well, I am the author and I am definitely a man.
You are aware, I hope, that Louis Proyect is the author of this post and is indeed a he. Yves introduced the article so perhaps she is the one you are confusing with the author. Try reading it.
You’re right, I don’t know COBOL. Big deal. I have worked on projects integrating fairly complex (though non financial) systems with legacy code, though nothing even remotely as swamp like as the descriptions of what is entailed here – and never under the conditions that would prevail for such a project in Greece – yet still I know perfectly well that doing patchwork integration (because the old code works and because no one wants to risk breaking it) is not done using OO languages and certainly not as time savers.
But most of all, you are picking at hairs or hair balls. There are so many difficult issues in a project of this scope that COBOL alone, even if you knew what YOU were talking about, simply wouldn’t matter.
It sounds as though you have not been reading the other recent posts on NC about this subject.
Note one can make procedural code using objects (a class simply defines a set of procedures) and as such that would work fine, but using full object oriented design for tying bits of legacy code together with minor modifications to support the Drachma or what have you would be pointless and prohibitively costly in design time.
I know COBOL, PL/1, Mainframe Assembler, a bit of C, Delphi and so on, and was an IT Consultant integrating legacy and “modern systems”. All modern systems become a part of the legacy patchwork, because no enterprise ever completely replaces all its legacy systems. My experience is little gets discarded and the integration links to other system multiply over time. Think n factorial in linkages or interfaces, where n increases every year.
I’d also expect the legacy code in Greece to be commented in Greek. Thus Non Greek speaking consultants need not apply, which would limit the possible skill pool.
There is a truism, if it isn’t tested it does not work. As stated finding the code to change is hard. Testing it, and fixing the errors induced is harder, because all that code is full of side effects. The tests have to be full tests of all the code. When a change is made in old code it is sometimes very complex to determine the scope of what’s been changed.
Testing also requires one know what is correct output and what is an error. That alone is hard.
Perhaps you could refer me to the page in the Enterprise PL/I manual that discusses classes, or methods. Here’s the link http://publibfp.boulder.ibm.com/epubs/pdf/c1472854.pdf for the latest Enterprise PL/I version. Yes PL/I does have some attributes to handle XML, but that is not a data format that is even remotely in general use for mainframe datasets.
Mainframe code tends to be old. We have production programs running unchanged since 1983. The authors are long gone. My bank still runs green screen applications for most of their backend, because it just works. Our largest client deploys application changes once a year. That’s all they have time for because of the immense block of testing that goes on to make sure everything works before it’s deployed to the public facing infrastructure.
Making changes to large IMS type applications is simply not trivial.
it also tends to depended on to work. and while some of the code could be from the 1980s, not all of it is.
I worked in mainframe IT financial systems, specifically as senior systems engineer, in which capacity I designed, coded, tested, and implemented complex projects.
Most of the article is RUBBISH! Given the systems extant are as poorly coded as implied above, they should be trashed!
If they are properly coded, adding the Drachma to the international system should be as simple as adding records to the data base, ie should take a day or two.
Now, the critical problem for Greece is re-asserting control over it’s domestic payments system,. This requires implementation of a firewall between the domestic payments system and the international payments system, to prevent the shutdown of the domestic system by the ECB for the purpose of coercing Greece to acquiesce to actions counter to it’s best interests. This does not require shifting to a new currency.
Once the domestic payments system is firewalled, an ExIm bank can be put between it and the international payments system, with the ECB conduit dead ended there. In it’s place the Bureau of Electronic Currency credits the GCB as necessary to ensure sufficient reserves are in the system for domestic payments to settle.
The next issue is bad bank loans. This is easily accomodated via a tax on debt instruments onerous enough to ensure all Greek banks turn in their entire loan porfolios for cash at 100 % of face value. The cash is created at the Bureau of Electronic Currency out of nothing at a computer keyboard on the master account which credits the Finance Ministry’s account with the required funds. The Finance Ministry can conduct a nationwide jubilee, knowing that no new monies will be created via issuance of private bank debt, relieving the population of it’s debt burden, and the rent seeking thereto.
Next is the issue of 18-24 unemployment. This can be dealt with via expansion of the existing national service system to cover all, eliminating unemployment in this age group and the revolutionary risk that entails, via payment of a small salary, room, board, and uniforms.
Next is the issue of International settlements. Trading in the GEURO, including capital movement must be restricted ala Malaysia/PRC. No free trading, at all. Only currency swaps.
Next, Greece will need a new suite of trading partners. The founding reason Greece joined the Euro was to obtain cheap energy using that currency. Russia has offered cheap energy and pipeline deals. Greece needs to make these happen, and to make deals with the PRC for PV and wind turbines, and electric vehicles to make Greece self sufficient in energy.
Greece need also tax the holders of it’s foreign debt the same as domestic holders, to force them to accept the GEURO in payment therefore, ala MMT theory. EIther they pay Greece onerous tax in EUROS/DOLLARS or settle for GEUROS, in effect legitimizing the GEURO.
This should take no more than 4 months to complete, with the Greek payments system operational immediately.
INDY
Most of the article is RUBBISH! Given the systems extant are as poorly coded as implied above, they should be trashed!
—
Ah, (slapping my forehead), why hadn’t I thought of that?
Well, Louis, ummm, he is right, somewhat. The systems are, no doubt, poorly coded and should be trashed. Of course that would mean starting from scratch and then Yves estimate of 8 years plus 3 years would be a serious underestimation.
Thanks to all for educational back and forth dynamic conversation. This latter bit reminds me that Obama’s argument for not doing single payer when he was first addressing the issue was that we would have to ‘start from scratch’. Instead, we got what we got.
I realize converting money systems is a far different kettle of fish, but I very much appreciate all explanations and ideas here.
Convert to the Drachma – Piece of Cake. Right…
Posted on July 15, 2015
These are people who almost certainly have never sat in cubicle and programmed a financial system in COBOL as I did for twenty years before I moved over to UNIX based systems at Columbia University. (1991) (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.)
WordPressure
Filed under: computers — louisproyect @ 4:46 pm
As some of you may know, I was a computer programmer for 44 years until my retirement in July 2012. I can’t say that I was any kind of genius but I managed mostly from being fired.
almost funny
This should take no more than 4 months to complete
I doubt the specs could be written in 4 months.
Or the systems affected identified, aka an inventory of the affected system.
I has a contract in the business call center, the customer call center, for a large medical provider, and the call centers system, complex in and of themselves, interface with over 40 back-end systems, from legacy to AIX to other Unix, Oracle, Sybase, and more technologies than I could list.
Re: “the commentariat also seem unable to grasp how changing this code is very labor intensive. ”
So it would create jobs? Wouldn’t that be a good thing ?
Yves and the author make it sound as if banking could not function without computers. Of course banks functioned before computers. We’ve done it before, we could do it again.
So banks could not readily access past financial records? OK, so do like the Germans did after WWII — forgive all debts and restart the economy with a clean slate. Wouldn’t that be a good thing? Wouldn’t it reduce inequality?
As I have commented previously, I agree that a Grexit would probably shut down the electronic payments system — so write checks instead. Government pays its bills with checks, businesses pays its employees with checks, workers pay their rent with checks, and so on. Worst case, banks would have to switch to paper ledgers like the old days. That would create jobs — GOOD !!!
It’s good to approach a Grexit with eyes wide open, but that should not be an excuse for inaction. Technical problems can be solved by Greeks, EU political problems cannot be solved by Greeks.
Banks functioned without computers when companies functioned without computers. The conceptual issue is the system. My phone charger works in the U.S., but not in France, because the systems are different. Now there are workarounds – a simple plug from REI will do the trick – but without the workaround, you can’t even fit the square plug into the round hole.
I agree with you it’s possible over time. All it takes is labor hours (including things that tend to get overlooked like vision and management). But the point is it doesn’t solve the immediate issue, and that’s where the operational details have appeared at least to really hit a nerve with economists like Mitchell.
Grexit can be a consequence of debt renunciation, but it does not replace the need to choose your personal preference of debt renunciation, taxation, and/or spending cuts. Sovereign money is irrelevant when your debt is dominated in some other currency.
Dan – Do you really think the banking system of any Western nation can handle the enormous flood of checks that would result? And what do you think happens when a check is presented for payment by one bank to another? All interbank clearing is done electronically, even paper check clearing. Are the banks going to start sending fleets of armored cars to each other to clear the checks?
Oh, and hiring lots of people to post to the paper ledgers is a recipe for disaster. I would bet that most of the people currently doing clerical bookkeeping would be lost if you gave them a set of paper ledgers with which to work.
Mr. Zelnicker,
Greece isn’t the US of A or China – it’s a small country. Person to person relationships are entirely possible in small countries. There are often times in retail situations, for one example, when computers and/or creditcard terminals aren’t working – then we employees simply whipped out our calculators and did the math for the sales tickets one at a time manually. Calculators don’t have to be connected to some overarching system. It was a tad slower, but we actually exercised our brains and that was a mighty good thing. Checks and cash work for that; credit cards don’t. Too bad for the credit card companies; I shed not one tear.
When computers started being state of the art in workplaces, I retired. I didn’t like the concept of collecting data on customers, and I still don’t. And the word is ‘customers’ not ‘consumers’.
Now, this has nothing to do with the complexities and technicalities of computerized financial transactions – I have to bow to the experts on that.
Louis, I do not have any experience in this field, so must go on what others say. However, James Galbraith and a Greek team have been working from early February until mid-July to fix this very problem and they think they have licked it. It no doubt will need tweaking, but they think the bones of the thing are in place. Here is Galbraith’s own statement: http://yanisvaroufakis.eu/2015/07/27/professor-james-k-galbraiths-statement-on-the-ministry-of-finance-working-group-convened-by-former-finance-minister-yanis-varoufakis/. This was done in secret and with some “misdirection” by Varoufakis.
Louis, I confess I don’t see any insuperable problems with ATMs. The Greeks can reintroduce bank tellers, like everyone had in the recent past. I agree this will introduce inconveniences, some possibly serious, depending on the situation of a given individual. But people can do without having to access an ATM. There will be problems associated with converting the ATMs to a new currency for reasons which have been mentioned and it will take time. But can’t we do without them for a time? I realize you didn’t explicitly mention ATMs, but they are going to be part of any IT solution should Greece exit.
“The Greeks can reintroduce bank tellers, like everyone had in the recent past. I agree this will introduce inconveniences…”
It’s more than “inconveniences”, as you put it somewhat airily. It’s physical constraints like premises (there’s only so many teller windows in a branch) and the ability to recruit, train, supervise and retain the tellers themselves. Plus basic inefficiency in a teller dispensing cash. That is why ATMs were introduced. In cash-only dispensing, they are able to service customers between 3 and 5 times as quickly as even the quickest, most experienced bank teller. In the medium term, if the ATMs stopped working, it would be impossible to handle the cash dispensing needs of the population. Even in the longer term, you’d be hard pressed to put in place enough capacity in large conurbations.
Teller inefficiency is not why ATMs were introduced. And you exaggerate it. I know from the experience of a friend who was a teller that they balanced their tills at the end of the day or they paid the difference out of their pay. Most were extremely efficient. And ATMs have their own inefficiencies, like failing to produce the cash, or not working at all. Speed of dispensing is not the only factor. People liked the personal touch working with a person on the other side of the counter provided. Some people still do.
It is true that they will have to alter their premises, but you make this out to be a bigger problem than it might be. Some banks will have more problems than others, to be sure, but they have done this before and can do it again. It isn’t rocket science. Your claim that it would be “impossible” to handle the cash dispensing needs of the population is unjustified given the evidence I have seen. Difficult, yes. Impossible, no.
Typical ATM dispense time is 42 seconds, some are a lot faster: http://adage.com/article/news/chase-seeks-competitive-edge-speedy-atm-transactions/113384/
Average human tellers cannot match that typical speed and certainly not the speed of a fast cash enabled ATM. Plus you mixed up teller accuracy / error rates with speed, not the same thing.
Clive, I don’t now where you access your ATMs, but I have yet to meet one that could carry out my instructions in 42 seconds. I haven’t confused error rate with speed. That is your own invention.I never contended that the teller could match the speed of an ATM.
It is not my data, it is JPM Chase’s. They will know a thing or two about customer-ATM dwell time and what is in the article I linked to is merely public domain information confirming what any TBTF would have as proprietary time and motion stats for its front office operations.
I’m glad we agree with the (pretty obvious) conclusion that ATM speed for cash withdrawals beats manual teller turnaround for the same transaction. So can I take this a step further that you’d also agree that having to decommission the Greek banks’ ATM estates because they couldn’t in any way quickly be changed to handle a Greek exit from the euro would place bank teller capacity under extreme stress as it would be the only channel available to service customer cash withdrawal needs ? During the recent Greek bank holiday, there were big queues at ATM machines. How could existing bank teller capacity handle the entire cash needs of the whole population ?
If people cannot conduct transactions electronically, can’t get cash out of ATMs and face huge queues at bank branches, you’re going to inflict a significant drag on the entire Greek economy just through lack of access to physical cash.
I certainly agree that bank tellers would have to take the place of the ATMs. I don’t think anyone would doubt that. How extreme the stress would be I think depends on the behavior of the Greek population and the way in which the Grexit is handled by the Greek government.
I would argue that the large queues we have seen have been significantly due to the fact that virtually everyone went every day, which should be a rarity after a Grexit. Thus, existing bank teller capacity should be able to handle their customer needs, though I would expect some stress at the beginning of the process; it may be that many banks would have to refurbish their branches in order to make room for more tellers and this would not be an insignificant matter to try to deal with. But not beyond Greek ingenuity I would have thought.
The drag you describe would initially probably exist but I think be temporary; how temporary and how significant will depend on the Greek government. I don’t see how we can predict the outcome in this detail in advance. The uncertainties are too great.
Notes from the Department of Not-So-Contemporary Analysis
I was a bank teller once. The job wasn’t horrible. It was a little boring, but not unbearable.
The hardest part was dealing with angry old ladies. They’d come in and ask you to do something impossible, like deposit money into their safe deposit box next Tuesday and give them a receipt today. You can’t do that, you’d tell them. They’d look at you hard, angry and peeved. Why not? Another teller did it for them, just last month. They’d start to shake.
Then you told them about bank procedures. That incensed them. They raised their voice so the whole lobby could hear, “If you don’t know what you’re doing I’m going to complain to the manager. You’ll see. The bank should have tellers that understand how to do things!”
The branch manager would look up from her desk and give you a quick smile across the room. Fortunately, she understood. She was pretty hot too! I still remember. Vivacious and breezy with dark brown hair. I think she was from Venezuela and married. I was about 19 years old, so I wouldn’t have been able to figure it out anyway. Still she was hot.
The old lady would finally leave, shaking with anger. But nobody paid any attention to her. Even the manager ignored her. All the other tellers, they’d focus on their business and maybe give you a quick grin.
That’s the way work should be. Sort of a comraderie like that. And if nutjobs mess with you, everybody rallies around. I don’t know what happened to “The Economy”. It’s not like that now in most places. That’s for sure. Maybe it never was, except in the hagiography of the past.
If Greece could figure out how to do that, they’d have all their problems solved at once. They don’t need money. They need comraderie, then they could make their own money, literally. Of course, if they could make their own money, they wouldn’t need the euro. That’s the problem, not the computers.
Why is it, do you suppose, that the younger generation never seem to know how to spell “camaraderie”? Or pronounce it? Why, it’s almost annoying as their putting “co-location” is scare quotes, calling attention to that facts that (1) they don’t know “collocation” is a real word, and (2) they clearly don’t know how to spell it.
This is total nonsense and effectively learned helplessness. To argue that it is impossible to simply dispense cash in the modern age is ridiculous. Ask a grocery cashier how difficult it is to scan goods, pack bags, handle cash, and maintain a pleasant attitude for 8-10 hours a day. Ask them how many people pass by their registers in a day.
It’s possible to go back to tellers. Ration bank account withdrawals like gas rationing. Odd numbers today, 2-6s on wednesdays, etc. Banks bash desk open 18 hours a day. Pre-withdrawal desks. Standard withdrawal amounts (Weeks worth of cash). Hire staff (christ knows there are enough Greeks/Europeans looking for work), have expierienced staff train and supervise. Expect to pay for them (and expect good work if you do). Fire any dead weight IT/Management if you’re running short on seats.
There are little old thing call cheque-books by the way (I’ve actually never used one), to take some of the pressure off big/unusual transactions too. Cowing in a corner and proclaiming then end is not a strategy. Neither is hope. But hoping for the best while preparing for the worst is.
Lordie.
Tell me how long this takes, and how Greece, which has had its economy fall to Great Depression bottom levels, deals with the damage.
We’ve told you it’s a minimum of a year to print and get enough currency in distribution. And the currency side is way easier to deal with than the bank IT side.
And we’ve also told you it is wildly impractical to deal in cash when handling imports, and that tourists won’t go to a place where they have to bring enough cash for the trip. No one is going to carry enough cash to rent a car. Most hotels would want a deposit over and above the room rate to cover possible damage and would want to be paid in advance of a stay. Many people use credit cards to finance their vacations. Etc.
Your response is equivalent to putting your fingers in your ears and yelling “Nah nah nah” when being told something you don’t want to hear.
You’re implying that because James Galbraith – who is an economist, not an IT professional – released a short, vague statement that refers to some (in all likelihood extremely preliminary) contingency planning with Yanis Varoufakis – who is also an economist, not an IT professional – that all the IT problems associated with a Grexit have been resolved?
Might I suggest you review the evidence and reconsider where this is even remotely plausible?
At any rate it is certainly not something either Galbraith or Varoufakis have said publicly.
Just my personal experience as a tourist (not in Greece): for at least a decade, ATMs have been the go-to place for changing money. (Story that might even apply in Greece: in Morocco, I planned on getting money from ATMs – but discovered, abruptly, that remembering my PIN as letters was a problem: all I could see were squiggles, aka Arabic. Fortunately, I remembered the positions, but now I know the PIN numerals. An Arab friend split a gut when he heard this story.)
Greece, even more than Morocco, is dependent on the tourist trade, so the ATMs are doubly important.
Sure, half a year and 1) they think that 2) the bones are in place. That’s an implementation schedule of, say, 1 January 2017. Maybe mid-year 2016 if government groups have been working seriously on it. Beginning of 2016 if Syriza was working on it while a minority party.
It doesn’t address the immediate budgetary quandary.
Also, it shows how behind the eight ball economists have been in recognizing problems. Greece has been coming to a head for basically the past decade, and they’ve been in outright bank run for five years. Galbraith started looking at the operational details of leaving the euro…in February(!)?
1. To dw: OO is not a magic bullet. I spent 10 years building Java applications at Columbia. OO is simply a way of creating and managing reusable software components so that inheritance is possible. For example, a class called Security can pass on its characteristics to ones called Stock and Bond. This has little to do with legacy software that is 15 years old in a Greek bank which was not written in OO.
2.:To Dan Lynch: “Yves and the author make it sound as if banking could not function without computers.” Er, that’s right.
3. To Larry: “However, James Galbraith and a Greek team have been working from early February until mid-July to fix this very problem and they think they have licked it.” I am not sure what “it” is but rest assured that it is not the IT that I was writing about. James Galbraith is a brilliant economist but has no experience building systems.
Louis, I agree that Galbraith may not himself posses such expertise. But one would expect members of his team to have it. It goes beyond credulity to believe that Greece lacks IT expertise, even of the kind you describe. Whether they could accomplish what he says was done, which was to prepare for a Grexit financially, in the time frame he describes, I don’t know. You may be right about that. But as Greece may well exit the Eurozone within the next few months, we only need wait for the consequent empirical test of the various hypotheses.
I wish the best for the Greek people. But given the behavior of Dijsselbloem and Schaeuble and the undemocratic status of the Eurogroup, it seems to me that it might be best for the population to exit the now tyrannical Eurozone sooner rather than later.
But one would expect members of his team to have it.
Particularly in large scale mission critical (fail safe) distributed projects where transactions and scalability are major elements (in other words, the very hardest of software systems to implement, modify, tweak, or often even to integrate with and test properly), there is an uncanny tendency for individuals to pop up in the software industry that thrive on convincing others (invariably with high positions but lacking in technical experience) that they have wings when in point of fact that is what they are most lacking. These are “hot shots” and thrive in situations where they won’t be involved with the result, but even when responsible for producing, they seem to have a certain facility with failure being somehow endowed with an equally uncanny ability to disappear into the woodwork.
In choosing an IT person to oversee a major project, one can almost invariably pick the individual who sees but problems and difficulties over one who does not and be correct (obviously other qualifications being involved).
As to Greece having IT experience available, it misses the point of time constraints, financial constraints, political constraints, staffing constraints, entirely. Under the very best of circumstances, this would be a project that could reasonably be produced in several years as long as it had lots of funding, a calm and enthusiastic political environment, and a highly trained and reliable staff, and most of all, no one needed it right away yesterday just to feed their families.
To # 1: Moreover, OO architecture is very hard to design unless one has or develops a particular knack for it and even harder to get right. It has been avoided by system programmers (such as general operating systems) at least up until recently for a variety of reasons. It would be most useful in situations involving a complete re-write or integration with an environment or framework already built of objects and inheritance. And a lot of that sounds like it would be a moot point here since, as described, legacy code of many varieties is such a major part of the issue. Even if one didn’t need to link to the legacy code, what would be the point of coming up with elegant and flexible OO solutions when much of the project would consist of integration with many many points of non OO code thus severely limiting it’s value.
And James Galbraith admitted as much on NPR this morning. Galbraith was asked how much his clandestine team had worked on drachma conversion. He said they discussed the “conversion concept” and potential ideas, but did NOT develop detailed, practical solutions.
(Galbraith said that his small group did not have a “mandate” to convert to drachma, so the depth of their discussion was neither long nor deep.)
do you have a link to this interview?
Here is the link to Galbraith’s statement on his work with the Greek FinMin since February 2015:
http://yanisvaroufakis.eu/2015/07/27/professor-james-k-galbraiths-statement-on-the-ministry-of-finance-working-group-convened-by-former-finance-minister-yanis-varoufakis/
Yannis says he discussed a way to hack the Income Tax debate to create debt instruments, which could be converted into drachmas at a push of a laptop button, only with his old chum Columbia I.T prof. Hatzitheodorou (who denies any overt act) and only a total of 5 others would have had any involvement. In other words, it sounds like he was just blowing smoke while rapping with Norman ‘Black Wednesday’ Lamont and some British stock broker type shilling under a fancy name.The whole thing is an exquisite British comedy and arose only because Krugman said he was disappointed the Greeks seemed incompetent which prodded Yanis into proving he wasn’t just incompetent but also utterly deranged and I.T illiterate. I suppose since Lamont was content with gentle Ealing Comedy, Yanis (former president of the Black Student Alliance of Essex University circa 1978 when Monty Python were still together) felt obliged to up the ante by depicting himself as a combination of the bumbling Mr. Bean and the hyper-articulate, but demented, Johnny English.
Thus Yves is completely in the right and it is a puzzle why so many Pundits completely ignored such an obvious point.
As she says, not only did the Greek public understand the importance of the Euro but even a Professor of Game Theory was finally able to get his head round it, though of course, as a Black Englishman he has to keep milking this for laughs.
that wasnt my point. it was that just because some thing is old doesnt mean it doesnt have newer features. nor does it mean that only the new stuff works. people usually wont keep the old if it really doesnt work. and some times being new is a good thing. just means that the bugs havent been found yet.
IT has just about since the beginning about the latest greatest buzz word. and thats cause its a lot easier to sell a new shinny object than the some times duller object.
and if i were to guess because new currencies arent exactly an unheard of event, maybe semi rare. that they should have a process to add new ones, replacing old ones with new ones (since countries have been known to do that. like when the euro came into existence for example).
now its likely to not be quick, 6 – 18 months would be pretty aggressive and optimistic too.
course the euro zone would also have the same problem.
Mulitiply initial time estimates by 3 and you’re more likely to come into the real interval. “6 – 18 months” becomes “18 – 54 months.” That seems more likely to me for the IT issues discussed in this posting, and the previous by Clive and Louis Proyect .
Thank you professor Proyect. I was puzzled by Bill Mitchell’s blog. Just he seemed so uncharacteristically angry at you and Yves and NC. ‘Twas weird. But I shouldn’t talk because my preference would be to call Tuttle. Screw the whole thing up so bad with backwash that the entire global IT financial snake pit would drown. And then start over. But the one overriding reality for Greece is not an IT nightmare – it is staying in the EU and the eurozone. Tsipras even said he chose the reforms because he and Greece felt an obligation to keep the EU alive, showing more consideration than the EU has shown Greece or Spain or Portugal or Ireland. Unfortunately due to the economic contract of the members, keeping the EU alive means keeping the euro “strong”. Keeping the euro strong means having expanding economies capable of bailing out the members’ debts in euro. But wait… creating expanding economies will deepen the debt, and so will austerity. And no IT code can change this fact. There’s something about money itself that makes no sense.
The problem arises if Greece IS forced out of the Eurozone as seems to be happening behind the scenes even now because of bad faith players making it just about impossible to stay in.
Then the IT nightmare materializes overnight. It remains very conceivable that the Drachma or like will become necessary. These posts explain just what an impossible nightmare that would be under the present circumstances. One can only assume that the push back to such an obvious technical dilemma is motivated by the same sort of sympathy for Greece that caused such incredible blind spots regarding Syriza and Tsipras.
Frankly, I wonder about the real world importance of all this speculation. The Greek government and people have shown a remarkable devotion to remaining in the Eurozone no matter how terrible the experience becomes, so unless the anti-Austerity parties can gain about 20% + support, they are not going to become a majority. In that case voluntary Grexit is off the table.
I predicted for months it would happen, but it appears the Greeks have decided that it’s better to bear those ills they have than to fly to others they know not of.
FORCED Grexit will still happen of course because the Germans want it, and I predict that will be sooner rather than later. But, that’s a very different story. If Greece is forced out then the EU will have to assume some responsibility for “easing the transition” if only in order to not appear to be total monsters and to get agreement within the EU. So, I would imagine there will be further discussions along the lines of Schäuble’s “what would it take to get you to leave” comments.
Part of the price for getting rid of Greece will probably be technical support for transferring the Greek banking system to the Drachma, as well as “humanitarian support.” That was always the plan, and it would allow the Germans to feel good about themselves as “wonderful people providing humanitarian help to Greece” all while utterly crushing them and forcing them out of the EU and it wouldn’t cost that much.
So, the coding problems and the IT problems can probably be overcome, because the Greeks wouldn’t be doing it all themselves amid massive attacks on the Greek banking system from the EU itself.
The software in every bank in the world is decades old; the question is whether Greek banks IT is still built upon pre-Y2K, pre-EUR, patched-up 1980-era in-house legacy systems.
I would not be so sure; since 1999, things have progressed. The simultaneous challenge of Y2K and EUR, as well as later developments in the finance sector in the EU, pushed European institutions to upgrade their IT to standard, more manageable software packages. At least the Greek National Bank has been using Temenos systems since then, while Alpha Bank has been using the Flexcube suite from the other major banking software vendor (now a division of Oracle) for a decade or so.
This should make a migration somewhat less harrowing and render most of those concerns about hunting for data fields with specific semantics in masses of COBOL code moot — at least for those banks that already upgraded to a modern IT system.
However, assuming those modern banking systems are comparable to ERP in non-banking firms, then I see at least two major technical hurdles:
a) If banks have not built the in-house know-how on managing and re-configuring their systems, they will have to scramble to get integrators like Cap Gemini and Accenture to do the work — and those “emergency” projects are even likelier to go over-budget, beyond schedule, and towards failure.
b) If banks have not resisted the temptation for wide-ranging customizations, then they will have to deal with all those non-standard extensions and altered modules, which usually hide plenty of nasty surprises when one attempts to re-configure a system assuming that the standard functionality is in place (customization very often break standard configuration parameters and require bespoke integration code).
I wouldn’t be so sure. I keep hearing anecdotes from consulting friends about how Bank XYZ, usually in pretty advanced markets, are running a patchwork of systems of the legacy banks the modern entity is made up of, i.e. the software of the various pre-M&A banks were never integrated!
and lest not talk about those new fangled systems with their unwanted features (blue screen of death any one?)
You’ve posted excellent articles on the IT conversion/modification issues. thanks.
To Bill Mitchell I’d just remind him of the great Yogi Berra quote:
“In theory, there is no difference between theory and practice; but in practice, there is always a difference.”
Once all the existing software fails (because it either was a giant merger project or a giant rube goldberg to begin with … then we will all have to go back to paperwork, file cabinets and clerks anyway. The first rule of software engineering is … don’t expect too much from automation, you are doing a manual operation more efficiently, not magic. The second rule of software engineering is … KISS. Anything beyond a thousand lines, can’t be understood by anyone.
As long as we violate those two rules because of blind ambition and greed … no amount of IT will save us. And even without automation, blind ambition and greed will give you the Soviet Union. I look forward to the future were I will stand in line for toilet paper, that they have run out of anyway.
derivative programmers going to war with integral programmers isn’t a good idea, but that never stops the critters from trying.
that”s pretty funny. and you get bonus points for brevity and crystalline metaphorical distillation!
Planned Parenthood: Dumb and Dumber
Like the Nazis, Illuminati, and all the other bipolar, murmuring morons, Planned Parenthood is a breeding program, breeding morons in, not out. It says so right in the title. And, if you look, you will see that all the churches are signed up, right along with G and NSF. Somebody has to feed the apes, just don’t let it be you.
Liberation from personal responsibility isn’t freedom; it’s slavery, to peer pressure majority rule, to feed the apes controlling it, its own worst enemy. Keeping 20 guys or gals around on disability checks in case you need one doesn’t confer competitive advantage. When you see a PG&E commercial promoting lesbian parenthood on your dime, are you going to hurry out and pay taxes?
Margaret Sanger: “choking human undergrowth” “morons and imbeciles” “the Minister is the man who can straighten out that idea if it ever occurs to any of their more rebellious members” “create a race of thoroughbreds.”
My wife was watching one of her religious programs the other day, and the preacher says that it’s ok for single women to raise children because they can appeal directly to God, while he was treating his daughter like a queen, to set her expectations. And he tells a joke, about a woman thanking God for groceries, delivered by the devil, a biased man concerned about her welfare.
If the critters are waiting for Trump to run out of material, they are waiting for something that isn’t going to happen. One way or the other, Trump gets paid. Let’s see; Ex/Im pork for highway pork, that’s Congress at work. Seems like just the other day the Cat CEO was boasting about a bull whip. I guess replacing labor with a dc computer and a middle class automaton to watch it wasn’t such a good idea after all.
Abortion isn’t a fight between good and evil. It’s a fight between stupid and stupid, for stupid, of, by and for stupid. What happens when two people row in opposite directions? What happens when one person with two oars rows in opposite directions? What do you expect to happen if you chase arbitrary RE inflation with natural resources?
A man is never going to understand a woman, and a woman is never going to understand a man, for a reason, and agency, I don’t know, let’s vote, isn’t the answer. The American Dream is a corporate welfare scam. Enter at your own risk. Labor has much better things to do.
Let’s see what happens? No thanks. The critters aren’t thankful for what they already have. Why give them an opportunity to complain, for more of the same?
At some point here, the little university media gangsters blowing the Internet bubble are going to run into the real mob. Having broken a few bones in my day, with and without the advantage of heavy equipment, I don’t need to watch the repeat to know what happens. When a gang surrounds a ringer, it’s what’s behind the gang that matters. They don’t call them ringers by accident.
“Dyin’ ain’t much of a livin’.”
Huh?
As one who had gone through Y2K and from 1979 to 2012 where the code customs differed widely, I would suggest this be thrown into the analysis.
If we are dealing with systems that currently manage currency transactions that contain Euro and non-Euro transactions, chances are that the addition or subtraction of another currency is not a big deal, but its minimum test time (to get through all monthly and quarterly-executing subsystems that rely on the data) would be at least 1-2 quarters (leaving year-end to be a scramble when you get there).
Data conversion – well, this is tougher when the source data is not reliable or not easily available – if so, add 2 to 4 more quarters.
Project size means another 2-4 quarters because these will be monster systems to muck with.
Finally, because there are money systems, the margin for error are about nil – those who gain from an error never report it and those who lose invariably will. So money systems (definition – involve claims to assets, no, say, internal forecasts of activities) involve another 2-4 quarters of testing above non-money systems (ask the brokerage IT guys about their change introduction times). While overlap exists, it is hard to see how this can come in much below 3 years even without skills-limitations.
I think the better parallel was the Withholding systems in the US for interest and other taxable non-labor flows (implemented in 1982, begun by my staff in 1980) as it was big, hit all money systems and had some skills limitations. Now the code base of these systems is probably 10-20 times what it was, given layers of system components. So instead of 2-3 years of those old easy days, try 4-6 yrs. All affected institutions (business,gov, etc) would be hacking away at the same time and have to arrange some type of parallel testing (among themselves) to be confident of going live.
The attempt here is to identify metrics of complexity and risk, not precise estimates. But it looks like a bear to me. The more I think about it, the more complex it is. Partial implementation does not appear any more possible that full implementation, though project schemes to defer the unnecessary (in quotes) are always floated – reality will not allow those in this case.
My head hurts and I have not scratched the surface.
I agree that adding a currency is not as complicated as converting an existing currency into another. The complication of conversion should therefore somehow be justified, have you heard or read the justification of also doing a conversion?
I’m in the IT biz, h/w not s/w but still …, Louis & Clive (+ other commentators) have pretty much nailed the difficulties of modifying, testing, and then deploying new code into an exiting, running, mission-critical system stuffed fully of dusty deck legacy. They are legion even before you get to what might be called the “user interface” aspects – in this case POSs, ATMs, PIN delivery, check clearing etc. Its not called spaghetti code for nothing (*).
However what has struck me is that there’s an assumption here that seems to be going without question: All the s/w that has to be changed is still available in source code form – be it COBOL, PL/1, Assembler, Fortran or whatever – and can be recompiled. Maybe in amongst the decades old stuff are binary blobs of machine code whose source has long since been lost and whose interface is barely defined/understood, if at all.
On a different note. All this long thread on the IT aspects of Grexit does in my mind is to, once again, raise the question I asked myself a long time ago and to which I have never had any kind of satisfactory answer. Why are those on the left (however strongly/weakly you may define that term) so utterly and pig-headedly resistant to the idea that if you are going to (persuade people to allow you to) change things then you might at least *try* to make the changes work. Here. In the Real. With all its complexities, interconnections, uncertainties.
What exactly is wrong with the left showing a little competence ? For a change.
not sure what this has to with being on the left …
or the right
course any thing that works usually gets tainted with that legacy label. it is well known to create new buizz words.
So, if I understand this correctly, this could also pose a problem in the US if we had to adapt to situations that were very different from the financial environment when this code was written. If we hit high interest rates like the 1970’s, or hyperinflation, are there hidden decision making algorithms in finance institution code that could blow up?
Re Greece, this is an interesting piece of the humanitarian crisis. The Greek banks or government would struggle to pay either the programmers, or the army of human employees to do what the code currently does re the Euro and interacting with the international banking system. And who has the vision and the power to implement it? I don’t work in this field. The only silver lining is see is that where official systems fail, unofficial systems evolve. People find currencies, even if it’s liquor and cigarettes. The Greeks have a reputation of being better and more effective at black market trading than most. They’ll need it.
But what what does this specific problem say about how fragile and inflexible IT systems are generally?
But what what does this specific problem say about how fragile and inflexible IT systems are generally?
—-
Pretty much everything. I could write a 10,000 word article on this someday when I am freed up from writing about climate change, film, revolutionary strategy and the other things I cover. For as long as I have been in the industry, there have always been nostrums about how to make everything so much more simple. In the 1970s the buzzword was programmerless programming. End users would ender parameters and bingo! Then you had all sorts of hype about structured design methodologies (SDM). The same kind of claim. Fast forward to the late 90s and OO becomes the magic bullet. It doesn’t matter. Large-scale software development and maintenance is a huge, time-consuming and expensive business. A lot of the problems has to do with the clash between expectations and the very nature of corporations, which is to treat employees like chattel even when they are relatively privileged. Columbia University has experienced about the same amount of failure as any big organization I’ve worked for. In 2000 or so they contracted with American Management Systems to implement a Facilities Management System that AMS would eventually market to other universities. Millions of dollars were spent. Once the system went into production, the user department decided it was not what they really wanted. This kind of thing goes on all the time.
cant forget generated code, 4th generation languages. c. c++ c#, java. ,net
and on and on
the IT industry is good a creating new buzz words.
we also tend to create basic stuff like operating systems from others.
like z/os, from OS/OS1/MVS
and Linux, android, OS X, windows, from unix
and on and on
Someone who knows ;-) … don’t worry, Big Data Analytics will save us all, just like Operations Research defeated the VietCong.
After the completion of the 4 week project to convert Greece back to the drachma, the same hot shots can fix the F-35! Piece of cake!
IIRC even negative deposit interest rates was a surprise to SWIFT just a few years ago. The issues here rather more complex.
There are other pitfalls. You would need to ensure that in all of your calculations you had changed all of the data structure, variables, etc to use Rosa’s instead of dollars. You would not want to mix units and get erroneous results, a la the disaster with the mars probe several years ago which mixed metric and imperial units.
I think you are right and that this is beyond the ability of the banks to handle, inside or outside greece. My own opinion is that they will be forced — by circumstances — to fall back on effectively manual systems. Transactions and accounts in new currency will be handled by clerks, using hastily prepared excel sheet formats for the purpose.
While I think that in theory this “Excel Fallback” could work, it would require a lot of co-ordination, planning, management and entail huge teething problems. This brings me to what I believe is the missing-link/corollary of your IT problem thesis. How many people in the banks know how to work without integrated, automated legacy IT systems?
It’s 2015. Ten years ago some company executive might have remembered a time before computers. But is there anyone left with the competence or experience to go back to basics. In short what I would ask is: Can anyone at the banks keep the lights on if the network cables are unplugged? More proactically, can anyone direct or lead the junior clerks in the task of doing the necessary work? Are there even “consultancy” firms to provide such a “solution”.
I think we’re 30 years into an IT and more importantly management revolution that has in effect turned corporate management minds into puddings. I think it’s possible to move to an “Excel Fallback”, but I don’t think the talent is there to lead an orderly — or indeed any — retreat. We hear a lot of talk of fears of “chaos” if things go wrong. I think that’s because our present “leaders”, private and public, know that they don’t know what they will need to do.
Great place to start if you need something to replace climate change as our scariest collective problem.
I’ve been asking people to re-read the story of the Tower of Babel, and then consider it again with the internet instead of a tower.
But, you must actually read it, do not for a minute believe you correctly remember the point of the story.
Try getting the HR managers, the financial managers, and the IT managers of a large corporation into one room to discuss something that requires coordination across all their systems–introduction of a custom-designed 401(k) plan for example, and you will soon get the point of the story of the Tower of Babel.
It’s where the English word “babble” comes from.
Even that is underselling it. If senior management wants that to happen, it will happen. HR/OB, IT/MIS, and finance/accounting are pretty tightly integrated within corporate strategy, relatively speaking. Plus you have in house counsel to help since that is largely a legal matter.
It’s more like getting a Greenpeace organizer, an oil lobbyists, and a car salesman to create a custom designed DC plan. None of them may even have heard of ERISA, never mind having any interest in working together.
Well said. Management seems to be under appreciated in its importance to large scale projects, and our leadership certainly hasn’t given much impetus for comfort on that front.
I think another major point is being overlooked, the focus as been solely on the banks themselves. It is a big project for them, but there is another side that is being overlooked and dwarfs the effort of internal changes.
Just because Greece drops the Euro as it’s currency, does not mean that businesses will drop the use of the Euro. They will be going back to the days of dealing with multiple currencies. This means multiple bank accounts. Operationally this means new bank accounts, new checks (IT New format Files for printing), positive pay files, new electronic payment files, new processes to move these new files, etc.
Clives example of a spider web and each node a system, could be expanded to a spider web of spider webs. These links were not built in a day, it took years and even decades.
For a lot of medium to large companies, this means duplicating all your existing flows with the bank. For smaller at a minimum they will have to have multiple accounts for the currencies they want to (Have To) do business in.
For electronic file transfers the banks do not have the resources to dedicate to getting everyone over at the same time. It usually takes me 90 days from end to end on setting up new flows with a bank. Can it be compressed? Yes it can, but only so much. You still have to design, code, and test. File Hand off’s and communication between your company and the bank is the bottle neck. The bank side you usually have a Rep as point, and an IT guy, plus their back office team. From the business side You usually have a team 2-5 people. (Business rep (stake holder), Business / Technical analyst, developer, IT Infrastructure team).
Multiply that by Tens of Thousands of business needing to do this all at once. Banks don’t have the internal resources to meet this, they have just enough to get by operationally on a day to day basis. This can not be easily scaled out, these are real money flows.
My; this makes my head spin. Who to believe; he said; she said.
What’s a layman to think.
Ok, MMT. Hire a bunch of un- or under employed programmers to do what it takes.
Please don’t tell me we need to stay under the neo-liberal thumb of the Troika(the Organs) just because it’s too hard to change. And is it even too hard?
He said; she said.
Personally I’d believe that
Economist from Australia “whose name must not be mentioned.”
It’s only he said/she said if you’re not willing to do the work of actually reading the material.
“It’s c-o-m-plicated.” Sheesh. There are days I think the left can’t fight its way into a paper bag.
“Just hire a bunch of un- or under employed programmers to do what it takes …” What if time itself is the critical requirement that it “takes”? Hiring a bunch, or a bigger bunch, of programmers, won’t buy you that.
It isn’t categorically true, on IT projects, that two programmers can finish the project in half the time that one would take to do it.’ One can’t start some phases until others are finished. Some circuits can only be wired in series, not in paraelle. So no, just throwing “resources” at a problem is not the way to solve it sooner.
Yeah, the irony in IT that is difficult for some non computer people to grasp is that adding more people in the middle of a project can potentially slow things down rather than speed things up.
Micky, that’s why this notion that changing currencies is easy is irresponsible. The drachma itself does not save Greece from the Evil Troika. The debts are in euros(!). Greece has insolvent banks, and the hard part is choosing who should eat the losses. At a basic level, your options are some combination of debt repudiation, taxation, and spending cuts.
One thing that a lot of people who aren’t dealing with software development day-to-day don’t realise is that while writing good code is hard enough, reverse engineering it is an order of magnitude or two harder and that’s when you’re dealing with good code.
For the old banking systems, you have to figure out the intent of the original author 30-40 years back, plus an accumulated, monstrous hairball of quick fixes. At this point it doesn’t matter if the code is OO, functional, procedural or handcrafted assembly written by someone stoned out of their minds. The programmers working to maintain the system normally aren’t the best, brightest and most senior either, more likely the cheapest and just-about-adequate ones because maintenance isn’t sexy and whatever top notch programmers the financial institution has are working on new projects that also have deadlines attached to them and often tight budgets.
There aren’t a lot of competent people that are willing and able to wander into that morass and do what it takes to get it cleaned up and fix the issue. In fact you may find more willing people than ones that are able – I made a pretty good living for a decade dealing with first generation trading systems (ie, stuff developed in the late 80s/early 90s and then carried forward for decades) that needed fixing and updating. Original authors are long gone, documentation is, err, sparse and you have a tight deadline because as usual in investment banking, everything needs to be completed yesterday.
Now look at an interconnected payment system that is even older, created using languages and technologies that people have been actively avoiding for decades and see how many people you can find who can do even a half baked job. Yes, they can possibly use the Euro conversion code as a starting point, but that is under the assumption that someone still knows where it is and how it works. That’s a pretty big assumption, especially given that this was supposed to be a one-way conversion with no way back.
Greece: the scissors trap
Filed under: Greece — louisproyect @ 6:11 pm July 15, 2015
Greece exiting the European Currency Union (which is not the same as the European Union) is not an impossibly difficult task. It is however, a major logistical operation that would require the full mobilisation of the resources of the state, and the backing of the citizenry to implement. Syriza have alway indicated that it was their intention to try to negotiate and remain in the Euro with improved conditions. Plan B would have been to create a new currency. Syriza were simply unprepared for plan B, and were left with no option but to swallow the poison and hope they will survive without the country descending into a nazi revival.
Could a future article flesh out just how much of the system-transition will have to happen internationally, outside of Greece?
What is known now, is that there are these technical barriers, but not the extent of the borders they span.
Given that information, it might be possible to try and find solutions for this problem, to help prepare for a potential future exit.
What would it take, to get financial institutions etc., to update their systems, in a way that would make a quick transition possible – e.g. being able to handle having multiple changeable currencies? (this would be done years and years in advance of any potential exit)
Perhaps regulations could be enforced, for implementing such changes, and this system could be tested out on a temporary basis with a foreign currency (or multiple foreign currencies).
You’d have to promote the flow of limited amounts of that foreign currency through different parts of the economy, to test it – but ignore the potential problems with this aspect of it (for sake of argument), and focus on the potential problems with everything else.
None of this is trying to sidestep the problems, it is acknowledging that they are valid, and trying to find a solution to them.
Other countries wanting to prepare for a potential exit from or breakup of the Euro, could benefit from such ideas.
This is why changing currencies is not a solution to the actual problem Greece confronts of insolvent banks. It is a very high risk, low return course of action. Greece already has a functioning internationally accepted currency with no transition needed – it’s called the euro.
I mean, even if it were technically possible to have a magic button in Excel that would update all of your company’s records dynamically from Currency A to Currency B, would you trust Microsoft to implement and maintain that? The issue isn’t just the records of financial institutions. It is the records of everybody, most of whom have no standing IT staff or budget for that kind of work in 2015.
The articles on the technical difficulties have been, to my understanding, focusing on the financial system mainly, not the difficulties within normal business of rejigging their accounting – the main problem with the technical/financial switchover, is how it will put a near-complete stop to international trade and to tourism, among many other serious things.
So, as long as the line of thought I’m exploring, might solve the financial system issues (given enough lead-time before an exit), I think that’d be the main critical barrier solved – business accounting would be an issue, sure, but not an apocalyptic one like waiting on a financial system transition to the new currency.
Note: When I say ‘solved’, I don’t mean solved for a country entering an immediate exit (nothing is solved in that case), this only presents a possible solution to the long-transition-delay issue, if a country has a lead-time of years for prepping the financial system as I describe.
My impression was this series was looking at the full range of the payments systems, but I take your point. The most important thing is the major financial institutions and their ability to transact internationally.
Everything happens electronically now (and has for decades). Credit cards, debit cards, checks, etc. You have to test all these things before going live. Especially when changing everything at once. I absolutely agree this is 100% doable.
But not in a timeframe to deal with the insolvency of the banks. Greeks have been withdrawing deposits for five years now, and there’s just nothing left. The banks are out of runway. It’s not an IT problem; it’s a fundamental question of political economy: who gets screwed from the inevitable consequences of fraud and mismanagement.
There is no specific IT white paper to write until you know the political desires. For example, are we saving the banks, or starting with new ones?
All this elitist talk! Of course it’s easy! 4 weeks. Just throw away all the existing codebase, and all the mainframes too. Just put in a bunch of Dells running windows 10. And if you write it in Go, it will be pre-deskilled and very stylish. Obviously what our ideas of currency is are going to have to be reparadigmed.
Not node.js?
Go is still in development. I don’t think it is sophisticated enough to handle this large and complex a project. I say this while I agree with you in principle.
I think that comment was ironic (hence my response).
However, it seems that a virtual inability to look at the organizational capacity of language ecosystems (dread word) is also ubiquitous.
This has been and no doubt will continue to be a very interesting social phenomenon; I don’t know quite what to make of it. Too much Matrix and V or Vendetta viewing?
“That is why it took eight years of planning and three years of conversion for the introduction of the euro to go smoothly.”
Yes, but the status quo in Greece is so poor that the introduction of the drachma doesn’t have to go smoothly to be a big improvement.
“In large organizations there are hugely cumbersome change management processes.”
Yes, I get this, I really do, but these processes are optional when the chips are down. I’ve been there, and seen it happen. I’m working on a project right now with a Jan 1, 2018 target and it will be challenging to meet that target. But if the CEO came by and told us to drop everything else, disregard the rulebook and work like dogs to just get a final number as fast as possible and he’d make it worth our while if we succeeded, we could probably be done in a month.
I think the basic disagreement is not on whether introducing the drachma would be extremely challenging or likely to fail (at first) in many spectacular ways. It’s just that some of us (myself included) think it will be worth it nonetheless and that people will find a way to manage until the systems are all updated and will find ways to update systems and processes faster than they would in a ‘BAU’ type project environment.
Ultimately, sovereignty is too important to let it be overruled by IT concerns, no matter how valid they are.
I get that “some of us (myself included) think it will be worth it nonetheless.” What follows will be a little testy, but just to get the point across–
The problem, here, is that the technical arguments used by “some of us” have been so sloppy, and so tendentious, and so personalized, and so “any stick to beat a dog,” that there’s no reason to think that “some of us” (whoever they might be) will be able to deliver on the sovereignty concerns either, because they wouldn’t be able to organize themselves into a paper bag. (I note, for example, that with “made it worth our while” you assume (a) that the Greek government has the budget and (b) there is a payments system operating. Kind of a chicken or egg situation, when you think about it.)
One common factor between the English revolutions of the 1600s, the American and French revolutions of the 1700s, the English working class “reform” movements of the 1880s is that there was an immense amount of use of the information technologies of the day: Committees of correspondence, broadsides, newspapers, pamphlets, books, and then of course meetings and speeches, and then legislative and committee work. All this work is highly skilled, and what (at least in part) the material basis of these revolutions. It feels to me like “some of” the “it’s really easy!” crowd would, in that context, have preferred to concentrate on building Ben Franklin a really cool printing press! Maybe in four-color! We can get the ink from France! rather than focusing on the actual work that others, besides themselves, must do, or the effects of their focus on others, or the enterprise (if one considers a revolution an enterprise).
I thank whatever gods there may be, if any, that Tsipras had the good judgment not to go ahead with Varoufakis’s hare-brained scheme.
UPDATE I love “people will find a way to manage.” Yes, their insulin, for example. Clue stick: There really are people — like, actual living breathing people — outside the cube. We’d like to think that a democratic government owes a duty of care to them. Most of the “It’s really easy!” crowd, being romantic, indeed juvenile, adventurists, do not agree.
My feeeling: the minimizers who insist “it’s easy” ought to be constrained to work on the problem till it’ solved. Then they can tell us how easy it was.
Some questions:
Is it really necessary to have 100% of all the features you ultimately want from a banking system working on day one?
If not, what would be the bare minimum necessary at launch?
And, how long would that bare minimum take to implement and test?
I work in software personally (embedded, with experience in medical ) and there is usually a roadmap of what features are needed and when. I have seen little discussion of this aspect in the above. Far more important than questions of which object-oriented language you are going to use are: what do you want the system to do – and when, and how are you going to test it?
One other observation: the ‘from scratch’ argument cuts both ways. I’m not trying to minimize the scope of the challenge, but if you start with a clean sheet of paper, it is often easier than if you have to modify/extend an existing codebase. You do have legacy systems you have to interface with that you can’t do anything about though.
to sum it up: you seem to say that Chamberlain was right in Munich.
What an idiotic comment. Again, I thank the God(ess)(e)(s) Of Your Choice, If Any, that Tsipras exercised sound judgment and put the kibosh on Varoufakis’s hare-brained scheme. If the commments in favor of it on this thread are representative of the 1000 hires he said he needed to implement it, the project was doomed in advance.
Greece and the European Union: First as Tragedy, Second as Farce, Thirdly as Vassal State by James Petras @ http://99getsmart.com/greece-and-the-european-union-first-as-tragedy-second-as-farce-thirdly-as-vassal-state/
I believe it would be useful to have the perspective(s) of IT programmers/coders in Greece itself, preferably individuals involved in the Banking and Business sectors. There are many with CS degrees from Great Britain and the US who could provide specific/concrete answers to some of the questions raised here.
It might also be possible (not sure) to receive useful background information on the overall state/level of IT in Greece today from the former FinMin’s friend who came to Greece and served as his IT adviser for several months. This person is a distinguished CS professor at Columbia, iirc …
Being a professor does not mean you have any knowledge of the banking IT environment. And the insane notion of e-mailing tax IDs and PINs makes one seriously question his expertise. No one with any banking knowledge would transmit such important information in such an insecure manner. The IRS doesn’t send PINs that way either.
Moreover, it isn’t as if there is such a thing a “Greek IT” or “Greek bank IT” that is somehow different from international norms.
The tone (maybe not the intent) of all these IT articles has sounded a bit like “TINA” or more like “TIN it A”.
Personally the social and political hurdles dwarf the IT challenges IMHO, and we should know the EU was designed to create such a straight jacket.
It sounds so neocon to appeal to the mechanical complexity of something as a reason not to change.
Somehow creating new derivatives and financial instruments as well as bailout programs, new regs, less regs, etc. don’t seem to be too constrained by IT incompetence or complexity.
I don’t understand how stating the objective technological constraints of a Grexit is the same thing as TINA. I have heard one variety or another of this argument for weeks now. The implication is that there was some solution at hand that Tsipras refused to take action on. Without going into this question that I plan to deal with in a future article, I am reminded of the problems Cuba faced in the early 90s when the USSR came to an end. The country went into a “special period” that led to widespread hunger. What exactly could the Cuban government have done to provide the recommended daily nutritional intake? If you state that this deep austerity at the hands of a government that nobody in their right mind could describe as “sellout” mean that you agree with Margaret Thatcher?
The Who, Magic Bus:
Better, perhaps, as a song than as a guide to strategy….
The post is not a TINA, it is a corrective to uninformed or wishful comments that dismiss the complexity and time-consuming nature of IT conversions. It’s not that it can’t be done, it’s that it can’t be done quickly or easily or cheaply. That is not TINA; that’s a realistic assessment of the work required to successfully complete a transition.
Casually dismissing key technical details and operational functionality of any aspect of a Grexit, not just IT, reminds me of this very funny math cartoon:
https://avionod.wordpress.com/2009/04/06/and-then-a-miracle-happens/
I’ve done a lot of data conversion.
If there is data in tables referring to euros, then the data needs to be converting 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. And Greece has few resources to help here.
Something else just occurred to me.
Maybe much of the software that runs Greek banks, ATMs, and finance isn’t Greek-based. Maybe it’s proprietary software that was written elsewhere and Greece doesn’t even have access to the source code.
I’d be especially concerned about the proprietary nature of the software that runs the ATM machines. I believe the ATM vendors would be more concerned about safeguarding the proprietary information in the software than the hardware. If I were an ATM vendor, I wouldn’t want to let anyone but my own employees touch the IP in the ATM. And, if I would ever consider letting a customer (bank) have access, it would have to be a customer better financed than anyone in Greece. Liability concerns would be paramount to me. And remember: It’s the software that makes an ATM an ATM. Without the software, an ATM is e-waste.
It turns out the dominance of finance capital has a material basis that can’t be wished away. Who knew?
Salutary, in its way. But should raise questions about the depth and character of the change we seek, no? If the point is to continue to play the same game with “our” money under their rules, ASSUME hell.
Yves, thank for the insights. The Pando interview was a very helpful summary of your point of view on Syriza. I hope you’ll allow a petty criticism of something which I’ve allowed to iritate me. That Einstein-insanity quote: “Insanity is doing the same thing over and over and expecting different results” — it’s as bogus as a three drachma note.
First, it’s misattributed, as is pointed out in many places, including Wikiquotes. Second, it is inconsistent with Einstein’s Spinozan outlook. Einstein believed in experiment only as confirmation of a correct theoretical point of view, and he was unabashed about asserting which took priority in case of conflict. When asked what if an experiment had failed to confirm correct theory, he would say, “Then I would have felt sorry for the dear Lord. The theory is correct.” (And Wikiquotes does confirm the genuineness of this one.)
Why would a scientist think like this? Consider. The inertial theory violated every known sublunary observation up to that time. And if you can’t bring yourself to believe that reforms, in the face of a long record of clear failures, deserve to be tried again and again, you are one of our conservative friends, rather than a progressive.
We are not talking about a failure of reforms. Reforms that were never implemented by definition are not a repetition of failure. They can’t be a repeat because they were not yet put into practice.
Repeating a failed strategy and expecting a different outcome with no change in condition and no change in characters is a prescription for failure. I am mystified at the efforts to depict Syriza’s conduct as anything other than the abject failure it was. Virtually any other course of action would have produced a less terrible outcome for the Greek people. The bad faith conduct ALONE played straight into the hands of the arch conservatives we’ve called the “ultras” like Schauble. He was vastly less powerfully positioned in February than he become over time. The French, who had supported Greece at the outset, aligned themselves with the rest of Europe as of roughly March. It was only to avert what they deemed to be an unduly risky outcome of a Grexit that they took up Greece’s case last month at the big summit that led to the agreement to give Greece a bridge loan so it could get a third bailout.
On the IT matter I have a question. I’ve an MSCS and have been in IT since for four (sic) decades. Everything you say about the IT difficulties is right on the mark. (Although I will note that when it’s a new rip-off of the public, implementation often seems to be almost instant.)
If anything, saying the conversion would take years understates the risk. Many of the desired resources would be hostile to the success of the conversion and the project would take place amid severe infrastructural difficulties. Many IT projects in much better circumstances are write-downs — total failures.
Are there ways to effectively devalue which bypass the need for a proper IT conversion to new currency?
An immediate change to the drachma isn’t needed when a neutral ‘digital cash’, that acts as global trading currency, can be implemented within several months. The brick and mortar businesses can act as the ATM for their own benefit to receive euros in exchange for digital cash with no fees involved for either party. The people of Greece have mobiles so they are not separated from the world. It seems everyone is going around some of the issues like allowing the people of Greece to start correcting the economy from within their own environment, they can get some traction organically without any cost – the other issues can keep going for years.
There is more to what I’m adding here but it pains me to read some of the comments. An economic system has been developed over several years to avoid such issues that Greece is going through. An intro to it can be seen here http://qwickpic.com It’s been tested with billion dollar processes during some live processes before being placed hiatus to expand it more. I maybe sticking my nose in here but wanted to add something to the issues.
Your suggestions fall into the basic, broad category of “a digital currency would solve most, if not all, of the problems which Greece would face if it exited the euro”. There main issue with your suggestion is that it confuses two things which sound similar (a digital currency which you’re viewing like an alternative to physical notes and coins but which you envisage operating in the same way as the existing card payments networks because transactions are electronic and don’t require the exchange of a physical token like cash) and the function of the existing card payments networks themselves, which is to facilitate payments. It is important when analysing what might be feasible should Greece end up leaving the Eurozone to consider both needs (the need for a currency in circulation to replace the euro which for the sake of convenience I’ll refer to the drachma from here on in and the payments networks which would have to be adapted to cope with the new currency) separately.
If you roll out a drachma as a replacement for the euro to meet the need for a new currency, you can as you say use some form of digital currency in lieu of physical notes and coins. This gives the appearance of solving the problem of manufacturing (“printing”) the currency and the necessary distributions of the correct quantities and denominations of notes and coins throughout Greece. I would stress that this is indeed a major problem and one that is not easily or quickly solved because manufacturing a new currency and then distributing it needs planning, physical resources like secure storage and labor to do the cash management. So I can quite understand why creative minds would seek to find a simpler solution. A digital currency would not need that physical product distribution and so seems like it overcomes a big hurdle which Greece would face. But in reality, all it does is exchange one set of problems (manufacture and distribution of a physical item – notes and coins) for another (the design, build and testing of an infrastructure – smartphone apps, stored value cards or other mobile form factors) which would be needed to allow people to use the new digital currency in a retail / merchant environment or web-based payment interfaces to allow people to settle things like taxes, utility bills, rents and suchlike online using a digital currency.
Obviously, this “digital currency infrastructure”, if I may call it that, doesn’t exist in Greece on any scale. Indeed, it doesn’t exist anywhere in the world apart from a few niche examples used by early adopters of things like Bitcoin. Am I being harsh in describing these as “hobbyist” ? From my perspective, working in the traditional payment / big finance industry, that is what they seem like to me in terms of their maturity.
It is at this point that proponents of a digital currency-based solution for a Greek euro exit often get a bit hazy and start implying that the traditional card payments infrastructure can somehow bridge the gap. You seem to be suggesting this when you refer to “businesses can act as the ATM for their own benefit to receive euros in exchange for digital…” which would require a merchant to take payments in euros and exchange them for the new digital currency. If it wasn’t physical currency euros being paid to the merchant in exchange for digital currency it would have to be card payments – as Naked Capitalism has pointed out at length, card payments are vital to the tourist industry and the tourist industry is vital to Greece’s economy. Now, either you’re proposing that the existing card payment infrastructure EPoS terminals can take a card payment from one of the existing card networks’ cards (VISA, MasterCard etc.), hold the payment in the terminal, then credit the mobile form factor for the digital currency (such as a smartphone app or stored value card or similar). If not that, then the merchant has to take physical euros in cash off the customer and then use the conventional EPoS terminal to credit the digital currency mobile form factor. But this would mean that the digital currency mobile form factor would have to comply with exactly the same specification that conventional card networks’ cards have to adhere to.
Before blithely coming up with ideas for how some new-fangled digital currency could work, I really urge any reader to review how onerous the current standards for the conventional card payments networks are. Here’s MasterCard’s merchant guide: http://www.mastercard.com/us/merchant/pdf/SPME-Entire_Manual_public.pdf. And that is just for merchants. Card issuers have an equally detailed set of requirements to fulfil for card manufacturing. Adding support for a digital currency mobile form factor to the existing card payments infrastructure while being backwards-compatible with the existing standards for “conventional” cards is a huge undertaking. Just reading the standards takes days, let alone understanding it and then coming up with a set of designs.
The card payments industry has recently introduced a modest change in the form of additional feature – support for Apple Pay. If I tell you that this incremental advance (it really is merely a re-use of the existing facility to handle contactless NFC enabled cards) took over two years of planning and testing (plus co-ordination between the myriad of actors in the payments industry) to deliver. The only significant change to the standards was PAN tokenisation which was previously an “option” for the EPoS terminals, this became a “mandatory” to allow card PANs to be selected in the Apple Pay “wallet” and then transmitted to the EPoS terminal securely. Two whole years. Just for that. What you’re suggesting implies not only passing of the unique ID for the form-factor information but also the stored value position change too between the digital currency and the EPoS terminal. So it could hardly be developed and rolled out any quicker than Apple Pay support.
Now, I might well have misunderstood you here. If you’re not suggesting that the existing conventional card payments networks’ infrastructure (such as EPoS terminals) is being changed to support a digital currency’s mobile form factor, then you are presumably talking about some other, new, equivalent ? In which case, you land on the big snake and go back to square-one – having to introduce a new, parallel, infrastructure to support the digital currency in every merchant and every bank in Greece. I’m open to sensible suggestions for how long that would take to achieve, say, a 95% penetration rate.
This could be a very big issue because you have to convert all the records for the current financial year from Euro’s to Drachma and reconcile them. It all has to balance, not just some of them. Do the Greek banks, all the banks and financial entities have enough money and skilled people to do it? British banks have had a very patchy record of later just implementing system upgrades never mind nation wide upgrades. The smart money will be on longer than expected with a high risk that someone gets it wrong.