Test Injection

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

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 OldFarts 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

EditText of this page (last edited February 24, 2011) or FindPage with title or text search