Refactoring and code ownership

So I've been given a pretty big chunk of Perl code to work with. It's about 30 pages of pure hell, all in one file, and considered unmaintainable by some. Of course the word unmaintainable is not in my vocabulary (and apparently not in Blogger's dictionary either), and somebody had to do the job, so the Refactorinator comes to the rescue.

At the surface level, refactoring Perl code is not that much different than refactoring C++.

1. Identify groups of variables that belong together, and group them into chunks / structs, that can be passed around between files and functions without creating too much clutter. 
2. Break up the monster functions into smaller functions. Passing data between functions should be easier because of step 1
3. Break up the monster file into multiple files, and hopefully never look at some of these files again. Hopefully at this point, we have arrived at some self-contained functions (step 2) with relatively short function signatures (step 1). 

OK, I realize there's nothing Perl-specific here, I guess I'll have to make another post about that. But perhaps the lesson I'm learning here is refactoring is pretty universal, as long as the language supports multiple files, struct-like constructs, and basic functions.

Am I regurgitating basics here, being Captain Obvious? Maybe so, but then if the principles and techniques I'm writing about are so basic, then why the hell do I so consistently come across code with exactly the same mistakes time and time again? The short answer is "up front cost". That's a cost a lot of people are hesitant to pay, especially if there are ownership issues:

• Code has no clear owner - why should i clean up somebody else's code?
• Code has an unfriendly owner - your cleanup is very much unappreciated, because the owner a) thinks refactoring is a waste of time or b) has a big refactoring plan in mind himself, which he'll probably never get around to, but in the meantime you shouldn't ruin his grand plan
• Code has another owner - even if he's friendly, why should you do his work. 
• Code has an owner that doesn't believe in refactoring
• Code has an owner that believes in refactoring in principle but never gets around to it in practice

At the end of the day, it is beneficial that every piece of code, no matter how amorphous or scary, has a clear owner. That owner can invest in cleanup and reap the long term benefits. Or he can choose to not invest and pay the price. It's fair either way. It's most important, however, to never get in a situation where noone invests and everyone pays the price.