
Why Do People Neglect Maintenance? - benbreen
http://themaintainers.org/blog/2019/7/30/why-do-people-neglect-maintenance
======
gerbilly
They neglect maintenance because we reward resolving outages and fighting
fires more than we do good stewardship.

Imagine the following scenario.

Acme Co. has some piece of software that is critical to the operation for
their business.

Dave is in charge of the software system. The software crashes often but Dave
is always there to save the day.

Dave often has to stay up all night and is seen fixing problems at the final
hour. Management takes notice of this and often sends out emails
congratulating Dave for his hard work.

One day Dave leaves, and is replaced by Amy. Amy takes over the system and
slowly and methodically fixes all the bugs that were causing the outages in
the software.¹

Over time the code becomes more reliable, till eventually it runs smoothly.

Now what would management say if you asked which programmer was better. They'd
likely say: "Amy is pretty good, but boy that guy Dave was a real rockstar!"

When you reward a behaviour, you will get more of it.

If you want software maintenance, then you need to reward it. But often,
perversely we reward its opposite.

I'm working mostly as an ops person these days, and if I do my job well it
makes my contribution look invisible. When things are going right, there won't
be anything to notice.

1: In other words, code maintenance.

~~~
ASalazarMX
Amy would have seemed as rockstar as Dave in the beginning, as she had to do
all his work plus diagnostics plus analysis and fixing. If she made sure to
inform what is she fixing, management would appreciate her more.

There are nefarious managers, but most times it's our own failings to
communicate that makes us invisible.

~~~
Draiken
Maybe I got unlucky in my career but I've worked with a "Dave" and an "Amy"
where the OP's description is spot on.

"Dave" got all the hero credit and "Amy" was deemed as nothing more than
someone average at her job.

While peers might now "Amy" is the real hero, non-technical people don't grasp
that very well. And unfortunately normally those are the managers and
executives.

~~~
nomel
If Dave brought up the system and features, from nothing to something, which
is where the difficulty is, then he probably should get more praise.

I think polishing or even refactoring an existing solution that now has well
defined and understood required features, corner cases, and quirks will always
be vastly easier than the unknowns involved in building something from
scratch.

~~~
gerbilly
No way, maintenance of a system , especially a critical system, is much much
harder than building from scratch.

------
jcadam
Early in my career, I got stuck doing a lot of software maintenance on legacy
systems (I suspect this permanently stunted my professional growth, but this
was during the great recession and I took whatever work I could find). It's a
hard rut to get out of - I spent a lot of time developing relevant skills in
my spare time.

Anyway, one place I worked had a 10 page procedure for building the system. It
involved running several scripts, logged into 2 or 3 different servers (we
were running Solaris 8 - which was already quite old by then) as different
users. About half the procedure was written down, the rest was unspoken and
passed down via oral tradition.

A particularly intelligent and motivated guy once took it upon himself to
unravel the whole mess and come up with a sane build solution. Unfortunately,
his quest was not approved by management, the time taken away from bug fixing
caused him to fall behind on "points" (i.e., number of tickets closed in the
bug tracker), and he was laid off. So we stuck to the old system that sort of
worked, most of the time.

Now, one of the user accounts that was required to build a certain module
belonged to a person that no longer worked at the company (let's call him
Steve - I don't remember his real name). We were certain there was a
permissions or environment issue somewhere, but were unable to track down the
specific reason why only Steve's user account could successfully build said
module. We were successfully ignoring this obviously absurd situation until we
got a new sysadmin....

The new sysadmin was unfortunately a very motivated guy who wanted to set
things in order. He reviewed all of the user accounts, noticed "Steve" no
longer worked for the company, and deleted his account. We were unable to
build until the backup containing Steve's account was restored.

We never fixed the FUBARed build procedure, mostly because our customer (this
was a defense contract, so the govt was the customer) didn't want to pay for
such an effort - every thing we did had to be tied back to a specific req
number in our system requirements specification (SRS). Fixing technical debt
was not covered in the SRS, so it never got fixed.

Eventually I was caught up in a mass layoff and went on to better things :)

~~~
ScottFree
What I got from your story was:

1) Long term software maintenance should not be treated like help desk ticket
work nor should it be dumped off on junior programmers. Every company should
have at least one guy who enjoys maintaining legacy systems and that should be
his sole job.

2) Make sure fixing technical debt is covered in the SRS.

~~~
jcadam
> Every company should have at least one guy who enjoys maintaining legacy
> systems and that should be his sole job.

That's a career death sentence. I suppose if I was retired and wanted a part-
time gig for extra money/amusement, I'd do it. But one thing I learned from
working maintenance early in my career was... don't do maintenance work.

~~~
GFischer
It is. Also, people don't want to do it for any amount of money.

I quit a previous job and took less money because I got moved to maintain the
crumbling Forte4GL core system - I did get a handsome raise for that, but the
writing was also on the wall as they were also working to replace it.
Migration project has been ongoing for 8 years and is nowhere near done, I
might have been able to retire before it's completed though. It was also soul-
sucking.

~~~
SteveGerencser
But there are people that love doing it. My wife is an example of one. To her
is it a great mystery novel where she gets to tease out all of the details and
try to understand why things were built the way they were. Then try to make
them 'better'.

Of course, she was a government employee (mil) and her career path was set
regardless of what she actually did and the pay level was set in stone
regardless of what she did as well. So there is that.

~~~
jplayer01
> Of course, she was a government employee (mil) and her career path was set
> regardless of what she actually did and the pay level was set in stone
> regardless of what she did as well. So there is that.

I mean, this is only relevant insofar as that this position allowed her to
pursue her interest in what kind of programming she wanted to do. In any
private company, the incentives are so perverse that she wouldn't have been
able to do any of it, but that wouldn't change her preferences. It's just
further indication that, given the right environment, there are people willing
to do this kind of thing.

------
baxtr
Interestingly this is also related to employee churn. New devs coming to our
company usually don’t want to “maintain and fix” the code of others. They’re
keen on building new stuff with the newest technology/stack. That adds to the
problem.

~~~
TheChaplain
Really? I'm quite to opposite, I love to look through old code, add missing
testcases and fix minor issues. It helps me greatly to learn the ins and outs
of the software.

~~~
dimitar
What if the code is written in Delphi, committed in SVN and you have to figure
out how to build it? True story..

~~~
hyperman1
Thats pretty tame. I once got a bug like: Some contractor wrote this, got mgmt
to get a new, insane deployment procedure scripted and deploy it on completely
the wrong server. Some days it produces a report, other days it swallows 16GB
and dies.

After he left we wrote the contents of his hard drive to this stack of CDs,
and they are scratchy enough to have data loss. Of course the prod executable
differs from all variants of code found on the CDs.

It turns out to be a custom reporting framework for producing exactly 1
report. For extra speed, it starts 100 threads but doesnt have any
synchronisation. Which turns out not to matter as they are all fighting for 1
DB connection.

You are not allowed to touch prod directly, but have to get some unix guy on
the phone so far to recover logs, executable, and config. And as that guy has
to support this mess, he hates your guts by association.

~~~
pnutjam
Can confirm, I've been the Unix guy.

------
lifeisstillgood
K.I.S.S

As I get older the simpler things seem so much more attractive - for example a
recent project is using lists of dicts (python base base base types) because
it's simple and easy to think about. It's recently got to the stage where "we
should use pandas dataframes" is entering my brain, but it has meant that we
focused on the business issues of handling the data not the issues of a large
third party code base (even a well run well thought out one)

Maintenance starts with not adding complexity to your code

~~~
TeMPOraL
I agree, with a caveat: don't do dumb things performance-wise.

The other day I worked with a Lisp code base that used built-in lists for
math-heavy code. The result had garbage performance and even looked less
readable than proper array-based code that loops on stuff imperatively.

------
qes
Threads like this really help me appreciate my workplace and stay confident in
applying pressure to reduce technical debt.

I've been the lead at a ~30 person, ~7 dev, ~$5M/yr company for 10 years. As
we've grown from < 10 people and 2-3 devs I've had to transition from doing
whatever I felt was needed as I found the time to having to get approval
across our departments and schedule work across quarters, years, and across a
handful or two more people, but I've always been afforded a good deal of trust
in my opinion and understanding of the costs and risks of technical debt.

I often second-guess my emphasis on improving existing code. To come even
remotely close to keeping up takes a lot of developer and QA time and has
opportunity cost.

Deep down I believe it's vitally important, but there's a nagging voice asking
if this is really worth it. Sometimes it turns out not to have been. More
often I look back and think that part we made better could've used even more
time investment.

Personally, I enjoy maintenance work. It's an opportunity to refine and
improve ideas I or others had previously. It's less uncertain - the big
picture is there, it has history, we've seen how it's expanded and changed
over time already, I don't have to try to predict the future as much as I make
architectural decisions.

Completing a significant refactoring effort is every bit as gratifying to me
as launching something new. Staying in one place for a decade has given me
opportunity to see through efforts that take years before all the pieces are
in place.

------
pontifier
I tend to neglect maintenance because it seems like I am always playing "catch
up". If something is working fine, then it's not on my radar.

Even if problems abound, if the thing will likely get me through my current
project, I'll drive that thing into the ground.

I drove my last car for over a year with one cylinder not working until
someone ran a red light and hit me.

Should I have fixed it? Probably, but in hindsight it didn't matter.

I have so much coming at me from every direction that maintenance is often a
luxury I don't have time for.

~~~
Jach
Everything has economic tradeoffs, triage is needed, but a big problem seems
to be a deep set belief that the maintenance you can achieve in x time/budget
won't actually pay for itself in fewer issues coming at you later that amount
to not paying a cost > x to address. Or similarly is not great enough or
frequent enough to create a feedback loop for compounded savings.

I don't want to discount just building things better to begin with though. For
all the buggy stuff out there limping along there's also plenty of stuff that
simply doesn't need maintenance, and another lot of stuff that only needs
trivial maintenance.

~~~
marcosdumay
Well, maintenance can have many different consequences. It can save more than
it costs on disaster aversion, it can save more than it costs on small
problems, it can save less than it costs on a disaster or small problems. If
done earlier it can reduce the cost of future maintenance by much more than it
costs, or it can reduce by less.

Doing it right on the first place has also all those possibilities, and the
risk that you may discover that you spent a lot of time doing the wrong thing
completely right.

------
Dowwie
Don't forget self maintainence, too!

Exercise, eating well, sleeping enough, socialising and having a little fun
are often treated as luxuries in many cultures yet are essential to
maintaining healthy living.

~~~
maartenh
Especially for us techies who easily live whole days solely in our heads, it's
very important to take time and maintain our mind and body.

And to keep doing that when there is (perceived) pressure. Don't drop self-
maintenance! That's self-sabotage!

------
chooseaname
Developers who do maintenance are seen (by other, typically greener,
developers[0]) as being less skilled than those who work on "new" projects.

Personally, I prefer a good mix. I like new development, but I also like
helping a business thrive and so I know that maintenance is a part of that.

[0] I am not convinced that most managers see it this same way. I think most
managers see the people they want on maintenance as some of their most
valuable employees.

~~~
naringas
a new project is much easier to do than having to deal with software a few
years old created by a parade of a dozen people

------
omeid2
The article has some good points but I think the primary issue is that of
economics, most organizations are too small for the cultural aspect to
override economic concerns.

Maintenance doesn't provide immediate economic value, not to customers, not to
board meetings, not to developers, not to managers promotions.

Developers like myself like it or not, maintenance is a strategic investment
driven by long term policy for which many organization have none or can't
afford one.

Joel Splosky once said "I can’t tell you how many times I’ve been frustrated
by programmers with crazy ideas that make sense in code but don’t make sense
in capitalism". I think it applies to cost of maintenance fairly reasonably.

~~~
ravenstine
By the time that outstanding tech debt becomes truly problematic, the original
authors have most likely moved companies. I think a lot of people know this
deep down, which is why so many of them don't go as far to build things on a
maintainable way. There's economics for the company, then there's economics
for the individual engineer.

~~~
pytester
Similarly, fixing that technical debt will likely look like pure overhead
while the benefit of "other people will finish future features faster and with
fewer bugs" gets socialized, realized diffusely and goes largely unrecognized
(except, if you're lucky, by the other developers themselves).

I learned that one the hard way. Features get priority because features have
got visibility.

The picture gets even worse when you consider the probability that fixing
technical debt will break things.

------
AlexTWithBeard
In day-to-day life a lot of maintenance is neglected because it simply doesn't
pay off.

My AC installer has recommended annual maintenance. $200 every year for him to
come and, essentially, look at the pipes.

So far it's been 15 years, no checkups, all is good. If something goes wrong,
the $3000 saved so far should be enough for most repairs I can think of.

~~~
adrianpike
> $3000 saved

oh man, I had an AC drain backup on a third floor condo once that drained in
between the walls in all the units below.

the unit owner reeeeeally should have gone with the checkup

~~~
war1025
It's all wasted money until it's not, right?

------
adamnemecek
No one gets promoted for maintaining things. It's all about delivering new
stuff.

~~~
leowoo91
A bit show-off but when you fix an existing issue that no one were able to,
that's also delivering.

~~~
goatinaboat
It will impress your fellow engineers but management won’t care at bonus time.
It’s the classic sysadmin’s dilemma: the better you are, the more the
organisation takes you for granted.

~~~
babesh
They will say that you did a good job fixing the issue but most mid level
managers won't give you a bonus for that. In fact, in the next breath, they
will criticize you for not putting in enough effort into introducing new tech.
Fixing the problem is an opportunity cost.

The only exception I have seen to the above is if you catch the eye of top
level engineering management by your actions.

I have seen major problems lingering for years because management's actions
have shown that they don't value problems being fixed.

Furthermore, when bugs become a priority, the metrics they care about are bug
fix time. You are better off not being associated with a difficult bug because
it lowers your close rate and lengthens your average time to close bugs.
Perverse incentives.

------
ThalesX
Large enterprise solutions usually have maintainers or source a company to do
maintaining for them.

Startups in today's world - not necessarily 'startups', but also new products
- move too fast for maintenance; by the time they pivot, the old stack is
easier to replace with whatever new fancy system was sold to stakeholders.

Also, most new software churned out today is built from some building blocks,
usually community maintained, so no one is going to hire a developer to
maintain
<insert_fancy_open_source_framework_that_is_heavily_used_and_actively_maintained_by_the_community>.

------
RonaldDR
It is disappointing how their post devolves into the same old tar pit of
racial intersectionality nonsense that stunts and atrophies the mind.

"Concierges paid minimum wage" … many concierges make immense amounts of money
for what they do, and often make more than manager of hotels. Most people
don't even realize that with overtime most of the hotel desk clerks make more
money than salaried managers at hotels. Not even to mention the hotel porters
that run the valet, that make immense amounts of money.

It's all just the intersectionality nonsense of privileged, sheltered navel
gazers that have no idea what goes on outside of their university and screens.

I really hope that this intersectionality degeneracy will be killed with fire
and relegated to the embarrassing and shameful pile of mass mental abuse and
degeneracy that it belongs. One can hope.

The worst part about it all is that it just utterly stultifies the mind like
any other abused person exhibits, that can only, e.g., reference anything and
everything through what their abuser would want or do. But, that was the point
after all, creating abused minds that can only think in subservient and
submissive ways. It's sad that that abuse of several generations now was
allowed to happen.

------
Pete_D
Here's a reason I heard once. I've never heard anyone else mention it, so it's
probably BS, maybe a lawyer or accountant can confirm or deny.

Developing new features is classed as "productive" or "R&D" or such, which
means companies can claim some kind of tech subsidy or tax rebate on
employees' wages for time spent doing it.

Maintenance tasks like fixing bugs and upgrading servers don't come under this
classification, so they can't.

The incentives are thus set up for upper management to push against and
actively neglect maintenance efforts.

------
PeterStuer
Pure maintenance is a grind to keep the status-quo. Ideally we would love
everything to be maintenance free.

There are exceptions to this. This usually occurs when the object or system to
maintain evokes an intrinsic positive emotional response as opposed to being
something purely functional or utilitarian.

Some people love maintaining e.g. old steam engines and keeping them in peak
condition. However, even in those cases it usually amounts to select parts of
the effort usually involving some physical/sensory satisfaction, while other
parts are still considered a chore.

------
technothrasher
"We are unsure how we feel about terms like 'cognitive bias'"

What the heck does that mean? They leave a big turd like that on the table and
then just move on without elaborating.

------
RonaldDR
That's an interesting question, because it is clearly a function of culture, a
culture of maintaining things. It is a culture that has to be fostered and
cultivated and … well … maintained. And just like things that are not
maintained, a culture of maintenance will not be maintained either if it is
not maintained.

The way I see it, maintenance is a function of values and whether one earned
what one has; a kind of positive self-fulfilling prophesy. It is why across
the board today you can see a crumbling of the maintenance culture at all
levels, even if there is clear clustering, from the poor who are given things
they don't have to earn anymore and therefore don't maintain anything, to the
top ruling class that has never maintained anything and has seen everything,
from the most solid castles, to human beings, to ships, to centuries old
culture and traditions as totally and utterly disposable if it even slightly
stands in their way of achieving their usually megalomanic personal gain; to
the common people today that have all manner of things, from phones to
telecommunications to television to flight to institutions to cars … literally
everything … yet lack any perspective whatsoever on how it was produced, the
thousands if not millions of prerequisite steps and failures and attempts it
took to produce what they just take for granted.

One that does not know the actual value of something will not and cannot ever
understand the notion of maintenance. It's a concept that even the ancients
knew, yet we have lost in many, if not most ways as people have lost all
manner of sense of value that they don't even value money anymore to such a
degree that they don't even think of it as anything but a mindless exercise
they engage in to do or acquire the thing that stimulates their primitive
impulses, whatever those may be.

I know some people are trying to push a maintenance culture again, by the
stick of enforcement, but reality is that it simply will not work as long as
the seemingly lasting negation of scarcity holds. Maybe one day people will
realize that all the promises to pay or be paid for the work they did, as
embodied in debt, is simply not going to be paid nor can be paid, and it all
comes crumbling down and a natural order of scarcity is established that will
make people want to maintain things, but until that time, this will only get
worse with every passing day as you chuck your $1,000 phone aside very year
for a new one without even a second thought.

------
temporallobe
I am dealing with a huge maintenance headache right now, upgrading an entire
set of ancient Rails applications from 4.2 to 5.x. It’s a monumental task that
involves fixing all the the things, from libraries to controllers to models to
rspec tests. We’ve literally waited 5 years to do this. Why? Because pushing
out cool new features have greater “business value” than maintenance. It’s all
customer-driven.

------
rafaelvasco
One of the strongest reasons is Minimum Effort Syndrome. People do everything
with a focus on having the minimum effort on everything. Maintenance takes
work, sweat, burns neurons. The same as admitting that you're wrong takes
effort. Giving preference when driving takes effort etc. Of course there's the
money factor too.

------
dmje
~grumble~ an SSL cert is up on my list of easy things to maintain ~grumble~

------
oldandtired
The problem of maintenance is not new and is a global problem. Global as in
any area that needs maintaining. This effects software systems, hardware
systems, legal, political, medical, buildings, equipment, biological, etc.,
etc,. etc.

In the great scheme of things, it is ignored because it is not seen as a "here
and now" problem. To see the importance of any form of maintenance in any
field, you have to have a long term view of things. You have to understand the
"costs" of not doing maintenance for the organisation or system in question.

I did not understand this long term view until I worked for someone who did
understand and who was able to articulate the "costs" of not doing
maintenance.

People talk about "tech debt", but are unable to articulate that every system
has a cost due to its usage. This is irrespective of whether or not it appears
to be bringing income into the organisation or system. This income can be
energy, finance (profit) or some other "thing".

We live in a world in which everything decays due to ongoing use. In the case
of computer systems, this decay can simply be based on changing requirements,
bugs, old code running in new environments, etc.

If you cannot understand that the "cost" you pay today will effect the "cost"
you pay later, then you'll not understand how important the art of maintenance
is.

The example that jcadam gives about being "stuck" doing maintenance on
"legacy" systems is a good example of the lessons about "cost" not being
understood by the organisation. From the point of view of maintenance,
anything you spend money to keep going is an "asset". It has a function that
brings about a benefit for the organisation or system to continue in its
existence. So, "legacy" systems are assets, if they need to exist then they
need maintenance.

However, organisations have a mentality of assigning various areas or systems
as "cost" centres and other areas and systems as "profit" centres. This
inherently works against both the organisation and the maintenance of its
"assets". The idea that some section or system is a "cost" centre is a
artifice of the "accountant" mentality. This mentality is very prevalent
through most organisations whether very small or very large and all the sizes
in-between.

Is there anything that can be done about it? If your organisation is
controlled by the "accountant" mentality then probably not. If this mentality
is not in charge, then you should be able to bring a case for maintenance to
those who have the authority to approve it. But, you need to show the benefits
both short-term and long-term for doing maintenance for your organisation.

~~~
0x445442
This is a great comment! From very early in my career I heard this "cost"
center classification and I never understood it. Unless a company's hand is
dictated by some type of external force such as regulation compliance, why on
earth would a company voluntarily keep a "cost" center? Either the ROI is
acceptable or it's not.

------
auiya
It all distills down to poor incentive structures

------
29athrowaway
Can't maintain them? Don't start them. The company is not your pet project's
daddy.

~~~
yjftsjthsd-h
It ... Kinda is? The company started the project long before I showed up,
continues to profit from the project, and is absolutely going to reap the
rewards of refusing to maintain the stupid thing. This isn't about other
people refusing to help with my favorite pet project, it's the company
refusing to act and its own best interests.

~~~
29athrowaway
Why do many companies have internal projects that do the same as well known
open source software? Because someone was bored, or wanted job security, or
wanted to feel needed.

You should not start a project if a readily available, production-strength
alternative exists unless you have a very good reason.

Internal projects usually arw underfunded and have bad UI.

------
unkulunkulu
From their front page:

> We act

> Maintaining self and society through reflection, research, and advocacy.

Where is something actual in the list of the ways they act?

~~~
yjftsjthsd-h
Advocacy is an action, and they appear to be driving enough events (per the
relevant menu item) to count.

