Why companies struggle with recalcitrant IT(economist.com)
economist.com
Why companies struggle with recalcitrant IT
https://www.economist.com/business/2020/07/18/why-companies-struggle-with-recalcitrant-it
21 comments
There are at least 2 different definitions of robustness that could be relevant here.
The legacy systems are likely to cover many more business corner cases, which is a kind of robustness.
However, legacy systems, developed before modern software engineering practices caught on in internal IT departments (no tests, no modularization, no QA, etc), are often very prone to crashes, freezes and all sorts of other bizarre behaviors, which is a different kind of robustness.
Of course, I'm absolutely sure that newly written software is often lacking in both kinds of robustness, perhaps with the same frequency as legacy software. But often times, when a company is replacing a legacy system with a new one, this second kind of robustness is taken care of with priority.
The legacy systems are likely to cover many more business corner cases, which is a kind of robustness.
However, legacy systems, developed before modern software engineering practices caught on in internal IT departments (no tests, no modularization, no QA, etc), are often very prone to crashes, freezes and all sorts of other bizarre behaviors, which is a different kind of robustness.
Of course, I'm absolutely sure that newly written software is often lacking in both kinds of robustness, perhaps with the same frequency as legacy software. But often times, when a company is replacing a legacy system with a new one, this second kind of robustness is taken care of with priority.
Companies are just resistant to change, period. It's a feature of human nature and is exacerbated in many companies cultures. Legacy stuff will always have an intrinsic advantage simply because it's low/no risk. New stuff always comes with some risk and most cultures within organizations are risk averse. The larger and older the organization the more true this generally is.
I wrote an article a while ago about this phenomenon in a DevOps context and how to overcome it: https://calebfornari.com/2019/12/28/subversive-devops/
I wrote an article a while ago about this phenomenon in a DevOps context and how to overcome it: https://calebfornari.com/2019/12/28/subversive-devops/
I only clicked the link to find out what 'recalcitrant' meant...
adjective: "having an obstinately uncooperative attitude towards authority or discipline"
Sounds like a lot of IT departments... :-)
Sounds like a lot of IT departments... :-)
Archive.is: http://archive.is/MjNtl
Paywall.
>Boeing’s 737 MAX aircraft were grounded in 2019 after two fatal crashes caused partly by a software flaw.
Hm, I thought it was more related to Boeing's management misrepresented MCAS to avoid scrutiny.
From wikipedia https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings :
> On the Boeing 737 MAX, MCAS was intended to mimic pitching behavior similar to aircraft in the previous generation of the series, the Boeing 737 NG. MCAS activated by input from only one of the airplane's two angle of attack sensors, making the system susceptible to a single point of failure. It could not be instinctively disabled by pulling on the control yoke. During aircraft certification, Boeing removed a description of MCAS in the MAX flight manuals, leaving pilots unaware of the system when the airplane entered service.[73]
Software can't invent sensor input. And hiding information from pilots being trained is not a software error.
But really this is just a good excuse to re-post Paul Ross's excellent talk on Blame and the Fallacy of Root Cause Analysis: https://pyvideo.org/pycon-uk-2017/blame-and-the-fallacy-of-r...
>Boeing’s 737 MAX aircraft were grounded in 2019 after two fatal crashes caused partly by a software flaw.
Hm, I thought it was more related to Boeing's management misrepresented MCAS to avoid scrutiny.
From wikipedia https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings :
> On the Boeing 737 MAX, MCAS was intended to mimic pitching behavior similar to aircraft in the previous generation of the series, the Boeing 737 NG. MCAS activated by input from only one of the airplane's two angle of attack sensors, making the system susceptible to a single point of failure. It could not be instinctively disabled by pulling on the control yoke. During aircraft certification, Boeing removed a description of MCAS in the MAX flight manuals, leaving pilots unaware of the system when the airplane entered service.[73]
Software can't invent sensor input. And hiding information from pilots being trained is not a software error.
But really this is just a good excuse to re-post Paul Ross's excellent talk on Blame and the Fallacy of Root Cause Analysis: https://pyvideo.org/pycon-uk-2017/blame-and-the-fallacy-of-r...
Having worked in safety critical systems software, I'd say it was a multipoint failure. While the initial problem was the decision to use MCAS to get through without retraining, any person working on the software should also have realized that relying on a single input is not ok.
It was management failure + requirements engineering failure + software engineering failure.
It was caused by management's greed and short-sightedness, but it could have been caught at more points in the process.
It was management failure + requirements engineering failure + software engineering failure.
It was caused by management's greed and short-sightedness, but it could have been caught at more points in the process.
Engineering and software can only push back if the environment allows it. If management has developed an environment of blame and where push back on requirements results in retaliation then the idea of free will are an illusion. But I don't know anything about Boeing's company culture.
> https://pyvideo.org/pycon-uk-2017/blame-and-the-fallacy-of-r...
That... seems like a really bad misrepresentation of root cause analysis. Or maybe a description of root cause analysis done very, very badly. In every description of it that I've seen it's stressed that assigning blame is an antipattern.
That... seems like a really bad misrepresentation of root cause analysis. Or maybe a description of root cause analysis done very, very badly. In every description of it that I've seen it's stressed that assigning blame is an antipattern.
[deleted]
Yes paywall but please support The Economist. They are one of the few great news sources left.
> Eventually the costs become too great to ignore, and companies must upgrade their systems. But that is the moment of maximum danger, for the new software must do everything that the half-understood old one does, and more. It is, to repeat a common but apposite analogy, like rebuilding an aircraft in flight.
I've always felt this analogy is wrong on many levels. I'm guessing most attempts at rebuilding an aircraft in flight would result in failure and death. While many of the rewrites I've heard if failed, few resulted in the death of a company. Not all rewrites come with the same risks and there are strategies to deal with the risks, such as the so called strangler strategy from Martin Fowler.
I feel like discipline, organization, proper budgeting and organizational resolve are strong predictors of success with rewrites. I couldn't say the same for rebuilding an aircraft in flight.
I've always felt this analogy is wrong on many levels. I'm guessing most attempts at rebuilding an aircraft in flight would result in failure and death. While many of the rewrites I've heard if failed, few resulted in the death of a company. Not all rewrites come with the same risks and there are strategies to deal with the risks, such as the so called strangler strategy from Martin Fowler.
I feel like discipline, organization, proper budgeting and organizational resolve are strong predictors of success with rewrites. I couldn't say the same for rebuilding an aircraft in flight.
Yeah, blame "IT", never the out of touch managers who are in charge of picking the team and projects. Classic The Economist attitude.
Market for Lemons and all that.
Market for Lemons and all that.
We all make enough mistakes to go around.
The article isn't blaming people. It's blaming old technology.
The economist is thinking at the economy-wide structural level. It would be a weird claim for the economist to make that the problem is just that people are promoting the wrong managers and that there's some simple fix for this problem.
>Coders under pressure to add nifty new features often cut corners, storing up problems for the (ever less distant) future.
I think we all just witnessed a blind squirrel almost finding a nut. The article largely demonstrates how befuddled traditional management is about how applying last century's manufacturing and order fulfillment management techniques to creative work is yielding disaster.
I think we all just witnessed a blind squirrel almost finding a nut. The article largely demonstrates how befuddled traditional management is about how applying last century's manufacturing and order fulfillment management techniques to creative work is yielding disaster.
Eventually, I understood that a "legacy system" is one that the speaker hasn't sold you.
translation: "Geeks refuse to act their part as blue-collar cost center. This 'raclcitrant' attitude has been addressed with out-sourcing (thank you GoldmanSachs for leading this effort), cloud computing (all roads must lead to Rome), and the on-going effort to reduce the personal computer to a curated tool controlled from central systems. This article is an update in the progress we have made to date."
> As software eats the world
you would think software develoers would be kings of this world. But alas, the folks who own `The Economist` do not wish to share the technocratic ("finance") perch with the emerging technocrats.
"We must keep the geeks out. They think too much."
> As software eats the world
you would think software develoers would be kings of this world. But alas, the folks who own `The Economist` do not wish to share the technocratic ("finance") perch with the emerging technocrats.
"We must keep the geeks out. They think too much."
I was reading through this and nodded along the way. This is common knowledge for like forever now.
This article does nothing but state the obvious. AGAIN. Wasted 5 minutes of my life.
This article does nothing but state the obvious. AGAIN. Wasted 5 minutes of my life.
If there is one area where new systems will have a hard time against the old, then it is robustness. To say that newly developed systems are more robust than old is quite the stretch. The sole act of being maintained long enough to be called "legacy" points towards robustness.