Economic downturn got you working in a CodeSewer? Well, here's the way out:

* Automate the process of generating automated functional tests.
** CaptureTransactions
** StripeRequirements
** EnterpriseFit
* Take your OldGuardDeveloper''''''s and set them to generating/writing test fixtures for the old system. Let 'em yammer - they're going to anyway. To make them realize they're doing something productive, have them fix all the bugs that come out of the woodwork once the automated tests kick in. There are plenty of scuttlers - or else what you have is not a CodeSewer.
* Once the old guard have got RegressionTest''''''s for a decent chunk of the crap, start a team of NewGuardDeveloper''''''s TDDing on them in a modern architecture. And if you don't know what a modern architecture is, go read the RubyOnRails book. That's a modern architecture. If you can find a better one, let the rest of us in on it.
* Now before you let the new guard at it, slip in one more story, this one at the very front and center, the top of the pile: '''"ContinuousIntegration between old and new architecture"'''. The new architecture must bridge to the old architecture at all stages of deployment. SpikeSolution that puppy.
* As the new architecture grows with each test, plan to migrate the old architecture SourceOfTruth(s) one release-sized chunk at a time. 

The result of TestInjection is that the new guard always work TestDrivenDevelopment on new architecture - they '''NeverRewriteOldCode'''. -- PeterMerel

It seems to me you're wasting a golden opportunity here. The old guard know the system, its quirks, and its unspoken requirements inside-out, and the new guard know and can sell the ExtremeNormalForm at the end of the rainbow. Don't keep these two camps separate, make them PairProgram together. The newbies will gain the domain knowledge (and the valuable skill of bringing LegacyCode under control) and the OldFart''''''s will get themselves up to speed on the new methodologies.

''You don't keep them separate. But by definition the old guard won't pair. They're turf defenders and no clever-clogs-consultant is going to shift them off their patch. If you are going to shift them, you need first for them to perceive their own obsolescence. Otherwise they simply regard the CodeSewer as a source of job security.''

''But they are also immensely valuable because they know the problem domain. They often are genuinely indispensable. And if they are productive at the start of your project generating the tests you want to inject, they will eventually either self-select as new guard developers or relegate themselves to maintenance work for as long as the maintenance work is available.''

This also begs the question, what about the OldGuardManager who won't let you do this work in the first place? -- IanOsgood

''You have to find a role for them. If you don't, they're gonna kill you.'' -- Pete
----
Why is it assumed that the old guard don't want to make things better and work on the new system?  --PeteHardie