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.
This is bad, of course, but it's generally how things go.
Engineers also sympathize/appreciate with improvements I've done just for my own sanity, like making the build pipeline faster.
None of these where things I did because someone told me to, they where things I do because I cared. Meanwhile plenty of my peers ignored the problems or couldn't be bothered to fix them.
All projects I lead always have the aspect of how are you going to maintain it when I'm gone. So I tend to "force" the project owner to spend money/time on simplifying unmaintainable parts of the infrastructure. They're always happy about these changes after the fact however.
It's also the opposite of what most big consulting firms do, because they do want to maintain a steady revenue stream from their clients.
I might enjoy making systems cleaner and more maintainable but if the incentives for my next promotion are "lead new large scale project to ship something a few times and maybe you can get a promo", why bother?
It's probably one of the worst parts of large-ish organizations
This is a general human nature thing, it's apparent everywhere in life:
"It's more attractive to create new problems than address existing ones"
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.
The more frustrating situation it needing to jump in and make a one-off fix to something that is at least notionally "modern". These can be just as impenetrable, but you have to hold your tongue much more (especially if some of the developers are still around), and there's generally a lot less kudos for sorting things out. Personal "favourite": debugging stuff that's virtually impossible to build locally "...because we've got this great CD pipeline".
You've been working with decent code, in that case.
The legacy stuff I come across isn't even testable without massive refactoring, even if the company allows you to do that in the first place.
Also, deprecated libraries for which there is no upgrade, which leads to further framework support issues (e.g. you can't upgrade X 'cos it doesn't support Y where swapping out X would take siginificant effort).
The worst problem I come across is spaghetti code where the business logic is ridiculously hard to follow, and it's not entirely clear if something is intentional or not, till you inevitably break it, and get an angry email from someone you didn't even know used the system.
Refactoring (for testing or not) is something you can do without the company 'allowing' it or adding 'dedicated trust work time' to the schedule. Sure, it does need buy-in from whoever reviews/signs off your commits if they bother to ask why you did that thing, and in pathological cases you'll have to keep a test suite to yourself / a local environment, but the social issues seem less of a barrier than people just throwing their hands up at perceived technical issues. I like recommending Feathers' Working Effectively With Legacy Code since it serves as a technical reference of solutions to the usual technical challenges/complaints that hang people up.
In some work environments you can easily take ownership of a project, and some not.
Cue 10 interdependent hooks.
Then some weird error relating to some obscure fax sending module reconverted into an email templating service would creep up somehow and have to be fixed before I could go back to debugging.
So, yeah. I churned, and went on to build new things.
This problem is because the old guard wants to move on from the problems they created. They want to play with new toys. So they hire new devs to do the work they don't want and "free" themselves for greenfield development (i.e. the exact opposite of how it should be managed).
They had sent a new guy with essentially no training and he had not done a bad job. He was just new and needed time to get up to speed. When I started working with him he clearly knew what he was doing. But we got everything working 1 day after I showed up, because I had been deploying this product for a few years already.
Management basically praised me and shat on the new guy. I felt like crap and took new guy aside. We became friends, but this hurt his review later on.
This would just massively increase churn. Old guys get sick of doing the same old crap especially when seeing the new guys get all the good stuff. So it increases the likelihood that people will just move around a lot more often in order to build that "new stuff". Eventually you'll have lots of companies saturated with "new stuff" that's no longer so new and nobody to maintain it because everybody knows the second you're too old in the company you get saddled with maintenance tasks.
> the old guard wants to move on from the problems they created
Just because it's old doesn't mean it's a problem. It still has to be maintained though, with higher effort since the technology may be outdated. Even the best designed systems become a chore to maintain when you have to do it for 10 years instead of doing anything new.
If it’s replacing sound code with a half-thought-out implementation, maybe not so great.