Why companies struggle with recalcitrant IT

https://www.economist.com/business/2020/07/18/why-companies-struggle-with-recalcitrant-it

by prostoalex • 6 years ago

12 19 6 years ago

economist.com

eNTi• 6 years ago

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.

wolfgke• 6 years ago

Archive.is: http://archive.is/MjNtl

alecco• 6 years ago

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.

scotth• 6 years ago

We all make enough mistakes to go around.

why_only_15• 6 years ago

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.

caymanjim• 6 years ago

The article isn't blaming people. It's blaming old technology.

q-base• 6 years ago

"With no legacy systems to maintain, and fewer old bugs to root out, their software is more robust and developers can spend more time on features that customers want."

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.

tsimionescu• 6 years ago

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.

ciguy• 6 years ago

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/

fnord1232• 6 years ago

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...

carlmr• 6 years ago

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.

fnord1232• 6 years ago

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.

brazzy• 6 years ago

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.

spectrum1234• 6 years ago

Yes paywall but please support The Economist. They are one of the few great news sources left.

amanzi• 6 years ago

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... :-)

eternalban• 6 years ago

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."

LegitGandalf• 6 years ago

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.

wisemanwillhear• 6 years ago

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.

cafard• 6 years ago

Eventually, I understood that a "legacy system" is one that the speaker hasn't sold you.

Why companies struggle with recalcitrant IT

Related Stories