
Why companies struggle with recalcitrant IT - prostoalex
https://www.economist.com/business/2020/07/18/why-companies-struggle-with-recalcitrant-it
======
q-base
"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
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
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/](https://calebfornari.com/2019/12/28/subversive-devops/)

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

------
wolfgke
Archive.is: [http://archive.is/MjNtl](http://archive.is/MjNtl)

------
fnord123
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](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...](https://pyvideo.org/pycon-
uk-2017/blame-and-the-fallacy-of-root-cause-analysis.html)

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

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

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

------
alecco
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
We all make enough mistakes to go around.

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

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

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

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

