Trying to take on legacy code can be quite difficult.  You need to understand the business logic.  You need to understand the underlying architecture.  You have to learn the new frameworks.  And you need to understand the why.  This difficulty is compounded when you not only have to wade through a morass of existing code that works, but the plethora of tables, stored procedures and business objects that have been retired but never actually removed from the codebase.  I'm not sure what the phenomen is, but some programmers are hoarders.  In another life, they'd be the person that has ten year old newspapers stacked up in a kitchen because they might need it one day.  Or they still have the key rack they made for Fathers Day in preschool with the garish purple paint and the bent nails because they can't bear to throw it out.

I think the other big trap that catches the developers out is the urban legend that rewriting the code is faster than refactoring.  So a whole bunch of new objects and new methods are made, new tables are introduced, and then finally, the new code is "pointed at".  The old code is no longer referenced or used, but it's never actually deleted.  Unfortunately, it stays there.  Eventually, the individual responsible leaves.  The old code still looks like it does the things that it's meant to do, but it doesn't actually do it anymore as it's been replaced and nothing points to it anymore.  Tools like resharper aren't able to recognise that they're not used because all the plumbing still exists!  These developers might not be code hoarders, but they nevertheless leave a trail of obsolete but apparently useful code in their wake.

Fixing the code hoarder is not so easy.  Educating in source control, wielding a stick perhaps.  Code metrics highlighting complexities?  Not sure.  When the culture is to comment out but leave in, that's a difficult thing to change.  When you use a source control system that's not really up to it, that's also very difficult to change.  Wielding the stick can be a little easier - a senior developer running through a code review.  Paired programming with a non code hoarder.  I'm not really sure, but it's something I'd love to figure out.

Fixing the rewriter?  Refactor.  Migrate the old code in small, bite size steps.  Refactor tables using database refactoring techniques.  You're actually changing the code instead.  The code evolves and morphs into the new code, and we're not left with a bunch of year old stale code that some other developer may have to wade through down the track, only to find out that it's a red herring.  Introducing effective refactoring tools can go a long way towards this.  Even simple things like allowing users to quickly change the names of variables and methods can quickly improve the quality of code - often to the point where the desire to rewrite is no longer an overriding desire.  As code evolves, obsolete code has a way of just disappearing, and the "rewritten" code just magically takes its place.  Introduction of database refactoring techniques and working with legacy code techniques.  Overall, in these cases it's more about education.  I often find that once I've shown somebody how to refactor towards the design goal, people take it on.  It's much easier both in the short term, and in the long term.