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.
>I love to look through old code, add missing testcases and fix minor issues.
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.
I like the definition of legacy code as untested code, since it means your fresh pile of untested crap is immediately legacy code someone will have to deal with later -- often yourself.
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.
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.
I actually quite enjoy the true mysteries that nobody has touched for years. It's a situation where you're expected to slink off into a corner and swear quietly for a few days, and nearly-certain hero status if you pull it off.
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".
