Inheriting legacy code gracefully

I started a new job recently and just as in many previous relationships, where I inherit code, there's a bit of a mess. I imagine other developers think of their code the same as I do. I'm proud of what I write and I get a lot of satisfaction seeing it work properly in production. There is a lot of invested emotion in the emotionless lines filled with funny words and letters.

So, i set out to learn how others have met this same challenge. In my search for tips on how to handle the situation, I put together this short list of thoughts and links.

Personal Thoughts and Findings

• Be courteous. You don't know the whole story yet. Ask lots of questions and be polite. Maybe the last guy was a jerk. Maybe not. Either way, try not to judge. The current team is faced with the same horrors you are.
• Find the middle ground The chance to just sit and refactor everything is minute - dude, you have work to do! A common solution, I found, is to use new work to refactor existing issues. The hard part is working on a module of a larger system. Some times, I've gotten away with wrapping my code with "connectors" - code that connects legacy stuff to newer stuff. An obvious solution to most, I'm sure, but it doesn't always work. Researching the affected code is REALLY important in determining a balanced solution.
• Ask for more time on tasks. If you are the estimate-maker, be as accurate as you can and if needed, explain that you will be making "performance enhancements." What? It's true! Some places may not be cool with spending time on the code base, but it many cases, it is necessary... finding an acceptable reason to extend the time can't be that hard.
• Speak up, be resolute, but do so with understanding I was hired for my experience and attitude. My thoughts and opinions on the project are important. Odds are, my fellow developers and project managers feel the same way. Make sure you are heard, but be prepared to listen.
• Insist on a discussion, but pick your battles wisely I prefer working with people that, at the very least, acknowledge my opinions as opposed to denying them outright. I think I have that relationship here and now it's just a matter of picking my battles. Knowing which tasks are worth implementing some refactoring is key.
• Be honest with yourself. The mindset and scope of the code "smells" are scary. But the people I work for and with are great people and I know that we can work together on improvements efficiently. If that wasn't the case, I'm not sure if taking on the task would be plausible - for me at least. Some people don't mind the code debt or code smells. Maybe it makes them feel comfortable. Maybe they just don't care. Either way, you need to be honest and ask yourself if you want to work like that.

Final thought

Regardless of skill level or the thought processes people ascribe to, being nonchalant towards the emotion coworkers pour in to their code will create more difficult relationships than beneficial friendships. Simply put: be cool, man.

Links

• http://programmers.stackexchange.com/questions/155488/ive-inherited-200k-lines-of-spaghetti-code-what-now/155505#155505
• http://thc.org/root/phun/unmaintain.html
• http://stackoverflow.com/a/206358/1936811
• http://programmers.stackexchange.com/questions/93872/handling-coding-standards-at-work-im-not-the-boss
• http://stackoverflow.com/questions/1112030/how-do-you-deal-with-bad-programmers