I’ve already been over Louis Proyect’s critical analysis of the chapter on the IT software problem in my new e-book. But in the comments on Proyect’s post a significant dialogue occurred between two commenters at NC: Ben Johannson and Clive. Here I analyze and comment on that exchange.
Ben Johannson’s initial comment to Proyect:
I’m reading here that Mitchell and Firestone are wrong because Bain and Google don’t do knowledge management. The rest is defensive polemics.
Apparently the higher up you are in the IT food chain, the easier it is to throw caution to the wind.
Ad hominem accusing Firestone of recklessness. I’m assuming it’s ad hominem, of course, as the other logical explanation is professional jealousy and resentment.
there is more to IT in Greece than banking and credit card processing.
strawman fallacy, as I see no evidence either Firestone or Mitchell suggested otherwise.
His tone reminded me of the one I take on issues such as when the Russian Revolution went off the rails but let’s leave that aside and move on to the substantive IT issues.
Appeal to emotion. Given you lack the mental superpower to pull another’s tone from their writing your attempt to make Firestone look silly is dismissed.
You can bet that if Greece ever needed consulting help to get them back into the drachma, there would be latter-day versions of AMS knocking at its doors.
How do you know they aren’t?
For Firestone to bridge the gap between Mitchell and myself, he invokes his own particular areas of expertise that supposedly get us closer to “it’s not rocket science”.
Your unconcealed hostility to anyone disagreeing with you makes the overall argument less than convincing.
In a section titled “Web-oriented Architecture Approach to a Drachma-based Transaction System”, he advises “web-enabling a legacy system”, something that might take a “few days, if that long”. Well, gosh, why hadn’t he brought that to Varoufakis’s attention?
You mock the idea yet provide no refutation of it. Temper, sir.
And then we get the attack on Firestone’s competence and his failure to be in the popular kid’s profession, so of course he’s stupid.
Of course, I agree with Ben in his reply to Proyect!
Clive then replies to Ben:
Ben, besides the well-known fallacies — which you rely on in your critique of Louis’s evaluation of Joe’s premise (that Greece’s euro exit contains significant IT work and that need for IT development will constrain what Greece is able to achieve in the short and medium term) — one trap which is also all-too-easy to fall into (and I have to watch myself because I can end up doing it as easily as anyone) is to pick on specific wording or phrasing. Every writer outside of the narrowest academic authors has to trade readability and grammatical shorthand against long, dry, technical description of the point they are making.
JMF: ?????? Clive seems to be saying that I don’t share the view that Grexit “. . . contains significant IT work and that need for IT development will constrain what Greece is able to achieve in the short and medium term.” But plainly I do agree with that view. Is Clive sure he’s read my actual suggestion in the book chapter.
If he has, then how about a quote supporting the interpretation of it he states? If, as he claims, I am not in agreement on this point, then why does he think I suggested the two alternative possibilities for putting a band-aid on the IT problem for the short-term?
Clive continues:
You chastise Louis for saying: “Apparently the higher up you are in the IT food chain, the easier it is to throw caution to the wind.” But this is merely expressing a well-known and generally accepted phenomena which leads to project failure. It’s referred more fancily as “optimism bias”. Many authoritative pieces of research have been done on this subject (e.g. http://www.nao.org.uk/wp-content/uploads/2013/12/10320-001-Over-optimism-in-government-projects.pdf). From the paper on pg. 6:
Complexity
5 The tendency to be overly optimistic leads public bodies to underestimate the delivery challenges of what are often complex projects. They may have financial and timing constraints, have multiple stakeholders, be interlinked or relate to other major projects, and be dependent on organisational or citizen behavioural changes.
6 (the Uk’s National Audit Office) back catalogue shows that, in planning projects, government does not always take time to understand the complexity and, as a result, over-estimates its ability to deal with the challenges. Too often, government commits to a ‘solution’ without fully understanding the context and exploring alternative options to determine which solution matches the real need.
Being the civil service, the report is written in a guarded style and so the catch-all term “government” is used, the “government” being referred to lacks agency in that section. But if you read the whole report, the “government” is actually ministerial direction as shown later in the report where the blame for a failed project is laid fair and square with “The Department for Communities and Local Government” i.e. the minister, who “tried to centrally impose a national control system”. It is senior level decision makers who are the worst exhibitors of optimism bias.
JMF: That’s all very well, and I certainly agree, but unless Clive can quote what I said in my book and show that I’m overly optimistic, then what does this all mean? It’s just a fancy labeling exercise with no proof saying “Joe’s overly optimistic.”
Clive again:
As for “there is more to IT in Greece than banking and credit card processing”, this is a true statement. Happy to be corrected if I’m wrong, but I don’t think that factually correct statements are straw manning.
JMF: This last is in reply to the statement of Ben’s that Clive had “strawmanned” Bill Mitchell and I in a previous reply. Well, here’s Wikipedia:
A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent’s argument, while actually refuting an argument which was not advanced by that opponent.
So, yes, Ben is right and Louis was “strawmanning” both Bill Mitchell and I, since neither of us ever claimed what Clive had previously quoted, or anything even close to that.
Clive once again to Ben:
You don’t like Louis’s writing style and allegory. That’s fine, but as I said at the top, it isn’t valid to criticise a writer’s style as a substitute for criticising the substance of their arguments. Louis pointed out that there was no evidence provided by Firestone to underpin some of the assertions which Firestone made. Louis was correct – Firestone came up with some valid wish-lists but did not evidence how they would be fulfilled. Condemning Louis for highlighting the evidential omissions in Firestone’s arguments isn’t a valid criticism which can be levelled at Louis. Put more simply, you can’t harangue Louis for pointing out the flaws in Firestone’s piece.
JMF: I proposed some alternatives to think about. That’s all. I also said I didn’t know if they would work, but suggested considering them. So, I didn’t make an argument asserting that the WOA approach would work and should not therefore be called upon to fulfill “evidential gaps” but only to engage in further discussion with others who will consider other alternatives with an open mind. I don’t know what “assertions” I have made that Clive finds unsubstantiated by evidence, but I miss either Louis or Clive quoting these in their arguments. So, if anyone is guilty of making assertions unsubstantiated by evidence, it is they. Where are their quotes, why are they relieved of the responsibility to present them, while I am charged with responsibility to produce evidence for assertions I have not made?
One thing I do know is that “solutions” to the IT problem of Grexit that take up to three years to implement are not acceptable solutions to the IT problem, since Greece may have to Grexit in the short run without very much of a grace period. And, if they do not have to Grexit and stay in the Eurozone for a long a period of time, then they will be an even more economically devastated country than they are now for a very long time.
Louis Proyect, Clive, Yves, and many commentators may be correct in assuming that Grexit isn’t a feasible solution, so that Greece will have just have to suffer until the rest of Europe comes to its senses. But this is not a solution which works for Greece, its people, or for any who sympathize with it or them. It is not even a solution which works for Germany. It only works for those interested in looting Greek public assets.
It may be that TINA is true here. But, I hope Clive will forgive me if I choose to pursue suggesting some possibilities which perhaps may overturn TINA, and which may be worth thinking through. The real question here, is why Clive and many others on the Naked Capitalism site aren’t joining me in trying to think of alternatives allowing Greece to Grexit very quickly, rather than just accepting TINA?
I don’t think suggesting alternatives is excessive optimism, which, again, is all I did. I hope these alternatives receive very exacting criticism, since the high cost of using a bad alternative is so high. But thus far, I don’t believe that my two suggestions about alternatives to TINA except mainframe application re-engineering, have received exacting criticism. How could they have received it when neither Clive nor Louis nor any of the commenters on Louis Proyect’s post at NC have even quoted my suggestions accurately and in detail? I don’t even see evidence that Clive has read the two alternatives I included in my chapter.
So, I ask for specific objections to specific proposals showing why they can’t work, not quotations about “excessive optimism” from government reports, or claims that I supposedly provided no evidence for my suggestions, when I never said that they were more than alternatives to think about, and presumably find evidence pro or con or both. What evidence do I need to get people to discuss the suggestions without dismissing them with general considerations which may or may not apply?
Clive continues:
There is a similar theme to your disliking Louis’s choice of words in making the case that converting legacy systems to web-enabled services is very difficult. This subject has already been covered extensively in the Naked Capitalism archives so you could look there for supportive evidence of Louis’s premise but really, it is not hard to find a significant body of well-respected, independent confirmation of Louis’s point.
JMF: Neither this “supportive evidence” nor the links to it were provided in Louis’s post. So, the fact is that he did nothing to cite cases that support his premise. Also, the points at issue are not points that Louis made about the difficulty of re-engineering mainframe transactional applications. There is no disagreement about assertions related to that point. The disagreement is over the possibility that my suggestions about alternative approaches are worth thinking about. And, if I am not mistaken there are no posts in NC archives that address the specific suggestions I raised or others like them. And, if Clive thinks there are then he must provide the citations involved.
Why citations are important, is because anyone can say that “supportive evidence” exists. But whether or not what they point to is really supportive evidence can only be determined by other evaluators if the “evidence” is cited and those evaluators can judge for themselves whether they apply to the arguments or claims they are supposed to be refuting. For example let’s take a look at the work Clive cites right after the above passage as “supporting evidence” for Louis’s assertions. Clive’s statement about this follows.
Clive:
One of the most comprehensive, again from the UK National Audit Office (who has had, erm, some experience of flushing vast sums of money and many decades of time down the drain doing post-mortems on IT train wrecks) who did a whole paper devoted to how big an ask it is to drag legacy systems into a web-enabled model and highlights several problems which are easily understood when well explained, such as:
Business transformation, including the drive for digital transformation is proving challenging for departments when it involves legacy ICT. Many legacy systems require data to be processed as a sequence of batches that is incompatible with a fully real-time digital service. In the pension system, for example, online applications have to be manually re-entered into the main system by a (Department of Work and Pensions) operator, as the website and the main legacy ICT system are not integrated. The approach of adding functionality through the addition of interfaces to the core legacy ICT is likely to be insufficient to achieve full digital transformation.
And as soon as you get into trying to “slap” a web front end onto an unchanged legacy system (the likelihood of this being required increases if you are attempting to web-enable legacy systems in very short timescales) then you actually defeat the object of your attempts to transform the legacy system into something a bit more modern because it increases the risk manual workarounds have to be put in place to glue everything together. Manual workarounds are the death-knell of the sorts of real-time processing which web enablement needs (emphasis mine):
JMF: Well, this sounds good, but it certainly doesn’t reflect my WOA proposal which is not limited to “slapping” a web front-end onto a legacy system. The WOA alternative includes “wrapping” the mainframe application so that it has an API exposing its functionality to a web-based network. Then it envisions integrating that component with another through web service-enabling it, and exposing it to other applications in the WOA.
The function is solely to convert Drachma inputs into euro inputs and euro outputs into Drachma outputs, into a “mashup” application that can process Drachma-denominated inputs in electronic currency into Drachma outputs in that currency with the mainframe euro-denominated application in the middle doing the processing, all so that the mainframe application doesn’t have to be re-engineered immediately to be usable in an immediate Grexit. The web front-end is then created for the “mash-up” application alone, and it is that composite application that supports using the new electronic currency during Grexit. This approach does not prevent manual processing of Drachma inputs and Drachma outputs through the web interface, if that’s necessary.
Clive (continuing his reply to Ben with his next quote, which by the way comes from p. 21 of the cited report):
We examine the impact of adopting a ‘no change’ approach to legacy ICT. Our findings are drawn from our case study of the Office of Fair Trading’s (OFT) consumer credit licensing service. A full report on this service is available at http://www.nao. org.uk/search/year/2013/monthnum/08/sector/ict-and-systems-analysis/type/report … business processes are typically adjusted to meet new requirements and may include additional manual processes. Introducing change in this way potentially offers the lowest capital cost and the lowest risk that service performance will deteriorate as a result of change. However, while it may allow an organisation to change its services to some degree, it is unlikely to reduce costs or improve performance. It is also unlikely that transformational change, such as introducing phone or web-based channels, could be delivered.This strategy therefore leaves the organisation exposed to the full risks of legacy ICT.
So, with a modicum of industry knowledge and subject matter expertise, I’ve been fairly easily able to find good quality, neutral, documented evidence to support Louis’s points. If you, as you undoubtedly do, take issue with what Louis has been saying, then I invite you to back up your counterarguments. Otherwise, you’re merely falling into the sort of blaming the rhetoric lazy logic you’re accusing Louis of.
JMF: Unfortunately this quote doesn’t support Louis’s points because it does nor refer to the approach of “wrapping” mainframe legacy applications. However, there is a quote from p. 25 of the same report quoted from by Clive that supports at least part of my suggestion without contradicting the rest:
3.1 In this part we examine the impact of adding functionality to a service through the addition of interfaces to other systems and applications, leaving core legacy ICT largely intact. The Department for Work and Pensions’ (DWP) pension service and HM Revenue & Customs’ (HMRC) VAT collection service were selected as case studies for this ‘enhance and maintain’ strategy. Both departments use software and system ‘wrappers’ around legacy ICT to deliver additional functionality. Our full analysis is available at www.nao.org.uk/search/year/2013/monthnum/08/sector/ict-and-systems-analysis/type/report.
3.2 The government has referred to this approach to ‘enhance and maintain’ as applying ‘wrappers’. This is government’s preferred option for dealing with legacy ICT. This approach can be used to make transformational change, for example, introducing online channels. This results in a more complex technology estate, which tends to increase the full cost of service and skill requirements. Introducing change in this way requires some capital investment, and is generally slow to implement and exposes the organisation to a risk that service performance will deteriorate if new technology does not work as planned. As legacy ICT remains, this strategy still leaves the organisation exposed to its inherent risks and in the longer term can be unsustainable as the complexity and cost of maintaining the ‘wrappers’ increases.
JMF: I agree with this statement. Please note that it says that “wrapping” can be used to make transformational change including online channels which is a central point behind my suggestion. Also, please note that the qualifying statements that follow this one say that 1) capital investment is necessary, 2) it’s generally slow to do the wrapping 3) there’s risk that performance will deteriorate, 4) it exposes the organization to risks inherent in the legacy application, and 5) it can be unsustainable in the long run for the reasons given. But the question is how do these problems impact my suggestion about using the WOA approach?
Well, 1) so some capital investment is necessary, so what? 2) If one uses an approach of coding one’s wrapper, then indeed it may be slow. But what if, if you use a development tool such as the two I linked to (then by all accounts the process isn’t slow at all). 3) Since the WOA solution envisions re-engineering the mainframe application over time as the Grexit is going on, then any performance deterioration over time can be avoided by using the re-engineered mainframe application. This makes clear that the WOA approach is not an alternative to the mainframe re-engineering approach; it’s just an alternative to the mainframe re-engineering alone approach. Instead, there’s an “and” here, not one or the other. That is WOA first, and, in parallel, mainframe re-engineering.
So, 4) since the mainframe application is getting re-engineered, then the risks inherent in the wrapping will be mitigated by the full-blown re-engineering effort as time goes on. Again, I’m not suggesting using WOA to avoid mainframe re-engineering, I’m suggesting it as a temporary expedient to allow Grexit to go on. Of course, the new mainframe application, when it is completed, would also be wrapped for WOA.
And (5) right, of course, the temporary expedient is unsustainable. But it is not intended to be sustainable. It is intended to allow the transition to Drachma, while the new mainframe application is being re-engineered and integrated into the WOA for the long term. Indeed, even mainframe maintenance can be incorporated into the WOA.
So, summarizing, the UK report cited by Clive actually tends to support my position when one looks more closely, and especially when one considers that my suggestion includes using web-enabling, and web services-enabling rapid application development tools with no language programming needed, a situation not envisioned in the UK report, or evidently, by either Louis or Clive.
I think that the lesson emerging from Clive’s comment is that when criticizing a suggested alternative, one needs to be careful to be specific and not to rely too heavily on general rules that do not relate to the specific suggestion being considered. I think that the Naked Capitalism critics are making many pronouncements of the very loose “lessons learned” variety, that are not specific enough to actually speak to the suggestions at hand. Specifically, the two suggestions I outlined in my chapter. I also think that successful criticisms of what I suggested need to be much more precise and focused on the specifics of my suggestions and not on more general classes of situations that do not apply to what actually has been suggested.
The exchange between Ben and Clive then continued further for another round:
Clive,
You argue that Louis’s statement to the effect IT is more than credit cards and hospitals is a true statement and therefore not a strawman. But a strawman is mischaracterizing someone else’s argument and Louis clearly implied that Joe and Mitchell ignore the complexity. It therefore is not material whether the statement is true.
There is a similar theme to your disliking Louis’s choice of words in making the case that converting legacy systems to web-enabled services is very difficult.
Doesn’t matter. Louis did not present such evidence, he simply indicated the idea is stupid and rapidly moved on. I applaud your technical knowledge but that isn’t the issue at hand. The logic and style of this person’s post are my concern and in my opinion both are sorely lacking.
I’ve refrained from commenting on this topic for months simply because I’ve watched people whose work I respect as well-argued go off the rails into exactly the sort of thing NC has stood as a bulwark against. Posting derogatory and inflamatory text like this is not only (in my opinion) beyond the pale but damned weird.
Sorry Ben, but in trying to make the case for Joe and Mitchell by refuting Louis’s piece you end up digging a deeper hole to fall into. When you suggest that Louis was straw manning because, as you correctly put it
“Louis clearly implied that Joe and Mitchell ignore the complexity.”
Yes, Louis did clearly imply that Joe and Mitchell ignored the complexity. In fact, he (Louis) wasn’t at all subtle about it — he came right on out and said it. He stated quite clearly that Joe and Mitchell were ignoring complexity. But I too have read the piece and my reading of it is exactly the same as Louis’s. I’ll say it here too: Joe and Mitchell, based on what was published, ignored the complexity.
JMF: I don’t think I ignored the complexity of the mainframe application at all. In fact, I acknowledged it, and then I proposed the alternatives as worth a discussion as possible ways to avoid the re-engineering of a complex application in the short run, by avoiding converting that mainframe application. That was the whole purpose of my approach to the software problem! I also said that in the longer run the mainframe application would have to be re-engineered due, in part, to its complexity and difficulty of maintenance. So, how was I ignoring “complexity,” or is Clive just saying that if someone suggests that it may not be necessary to re-engineer that application to perform Grexit successfully, they are doomed to failure. If so, then a proof of that conclusion is not in evidence in his comments, or in Louis’s blogs on this subject, or anywhere else on the Naked Capitalism site, or anywhere else, so far as I know.
Clive continues:
The whole thrust of Joe’s article was that suggestions that Greece would have difficulties in implementing the necessary changes to the IT systems in the financial infrastructure of the country was just naysaying and that there were solutions which could be implemented fairly easily and quickly if only people were willing to look for them. Now, you’d no doubt call what I’ve just done there “straw manning”. But I would call it what it is (certainly it is what I am attempting to do): “summarising”.
JMF: Clive is simply wrong about this. I never said that such suggestions were “just naysaying,” nor did I imply that. On the contrary, I said I was persuaded about the complexity of a conversion by their very posts in my book, and that consequently I favored an approach that would avoid conversion in the short run. Nor did I suggest that any permanent solutions to the IT problem could be implemented quickly, but only that there were alternatives that would allow Grexit while the longer-term software conversion project was going on.
So, I think Clive is not just “summarizing” what I said, but rather is “absolutely mis-characterizing it,” compounding Louis’s previous “straw-manning” as well as his own. If Clive doubts this claim, then I challenge him to quote the e-book to the contrary, or forever hold his peace.
Clive continues:
If after reading Joe’s work you come to the conclusion that it is indeed a description of the complexities which are inherent in migrating the IT systems in the Greek financial system from the euro to a new currency then, well, we must be reading entirely different articles. Joe’s feature does not make that point. It makes completely the opposite point. Me saying that is not straw manning. It’s making an accurate précis.
Joe is wrong. Louis is right. I was about to add in a run-on sentence “in my humble opinion”. But that’s just the point: it’s not either my opinion or Louis’s. We can both point to significant bodies of work which substantiate our positions. Louis didn’t apparently feel the need to go to town with endless footnotes and links like some college dissertation.
But that doesn’t make what Louis wrote wrong just because his article wasn’t peppered with links to other pieces which are easy to locate in the Naked Capitalism archives. I’ve found plenty of supporting evidence myself elsewhere which I linked to in my above comment. So I’m happy to concur with Louis.
If you think we’re wrong, then the onus is still on you to provide supporting evidence and facts.
JMF: First of all, my “article” wasn’t an article. It was a chapter in the book, suggesting again that Clive has not read it. But, apart from that, of course, and once again, I didn’t make the case that the mainframe application was characterized by complexity. That case had already been made convincingly to me by the NC bloggers and commenters, including Clive.
I was suggesting, once again, that its complexity was not enough to conclude that an immediate uncooperative Grexit wasn’t feasible, because there might be ways of avoiding changing the very complex mainframe application in the short run that would allow Grexit to occur.
Why is it so hard to convey this point to the NC bloggers and commenters and to get them to discuss why specific alternatives that seek to avoid changes to the mainframe application for the short run are unfeasible? Why are their minds so closed against discussion of such possibilities. Why do they keep coming back to the thousands of difficulties involved in re-engineering the mainframe application, rather than avoiding doing that?
OK, folks, point taken. It was taken at the beginning of my chapter on the IT software problem in my e-book. Can we please move on now to discuss whether problems of the mainframe application can be avoided for purposes of Grexit by the two alternatives I suggested or by others we can collectively think of?
8 responses to “Grexit: Exchanges on the IT Problem Continue”