Fixing old code can be a very satisfying experience. However this is usually tempered by management apathy for code maintenance. It's an invisible problem; nobody can see when you fix a piece of bad code unless it's causing a bug. This becomes aggravated when "25% of the people doing maintenance are students and up to 61% are new hires".
To management it's, at best, an "if it ain't broke don't fix it" attitude. At worst they consider programmers prima donnas. It's immensely frustrating trying to convince them of the utility of code maintenance, even when doing so pays dividends in future feature development flexibility and bug fixing.
I would love to see some strategies for convincing management of the virtues of maintenance.
You do that by understanding some of the tradeoffs involved and showing that you understand that maintenance for the sake of maintenance is usually a waste of time.
* If it was causing some immediate issue or had a bug that needed to be fixed you could justify it that way, but all too often someone wants to refactor something to make it "nicer"
* Code that's rewritten is going to have all new bugs of its own, those are going to end up wasting more time than the time spent on the initial rewrite.
* A lot of programmers will get the urge to rewrite something before they fully understand the system they're rewriting (and thus aren't qualified to do so). You might be 90% through rewriting it to be nicer only to discover that the remaining 10% doesn't fit with your design. There was some design requirement that you missed which caused the initial code to be so convoluted and "nasty" in the first place, because it was solving a tricky problem in some non-obvious way.
* In a growing business requirements change all the time, maybe you'll spend 6 months now rewriting some system to be nicer, but 2 years down the line it turns out that that system was inherently broken and has to be thrown away and replaced. So it would have been better to commit 1 month of time over those 2 years to keep it on life-support.
* Speaking of resource allocation: Is now the right time to do this, you probably have a 100 tasks with manpower to accomplish 10 of them. Maybe this is better done in half a year when you have more hires, or not at all if some of those other 90 things are more important.
But finally, if it's really the right thing to do just do it incrementally as part of other tasks. If it's really code you're working on all the time, and fixing certain issues saves you time down the line just make those fixes along with other tasks.
The only time I perform maintenance is when I'm adding a new feature. Before I add any new code I'll inspect the code that will be touched by the new code. If it's hard to understand or the abstractions are a bit wonky for what I want to add then I'll spend some time refactoring it. In this way your maintenance work is always done while delivering observable value to the business. You don't need to provide any justification for it. If it means you're going to take a bit longer to deliver a feature than expected you can just tell your boss that the code wasn't in the state that you expected when you gave an estimate. If you wrote the code in the first place it's fine as well. You can just say that the priority at the time was to get the feature out fast so there wasn't time to shine it up.
Refactoring is important and management should be convinced for this. Most managers also insist that the (physical!) desktops are kept clean. For the same reason code bases should be kept clean. The reason in both cases: Dirt slows down in the long run.
To management it's, at best, an "if it ain't broke don't fix it" attitude. At worst they consider programmers prima donnas. It's immensely frustrating trying to convince them of the utility of code maintenance, even when doing so pays dividends in future feature development flexibility and bug fixing.
I would love to see some strategies for convincing management of the virtues of maintenance.