A while back I was working on some huge legacy security component. I found it quite challenging, especially the legacy code part of it. Afterwards I thought about writing a blog post on "tips for working with legacy code". While I never got around to that, I did recently finish reading Michael Feather's excellent book Working Effectively with Legacy Code. His book is infinitely better than any measly blog post I could have come up with.
This book is awesome. I encounter people who effectively (and naively) say "just write it perfectly the first time." However, that misses the point. For example, many devs weren't even around when the system was first written - they're inheriting someone else's code. The author tackles the problems head-on with concise examples and clear guidance. The book has three parts: the first part starts as a general overview and then explains why this is really a problem, the second part offers tons of practical ways to test difficult code, and the third part explains how to break dependencies so that the code is no longer so tightly-coupled.
Two main themes of the book are (A) you want to be able to somehow write unit tests for this code, and (B) tightly-coupled code makes that very difficult. For example, if you've got a some "Employee" object, and its constructor requires a live database connection, singleton references, external configs, and web HttpContext access (like session state), you're somewhat screwed. He then proceeds to show how to salvage that situation by making low-risk changes that allow you to pull the code into test harnesses.
You've got to love empathetic chapters like "it takes forever to make a change" and "I can't get this class into a test harness". I think this is a perfect book for anyone dealing with legacy code.