First of all TDD is a significant change in approach, there will be more than a few get it out of the door types saying things like "Well if we get it right we won't have to test it", or "Yes, that's a great idea we'll do it next version", some of them won't be in management either....

The initial time investment in gearing up to do TDD is significant, and even if you've just done it at school, it's so foreign to the way most of us have worked traditionally (write bugs then, find them), there's a pretty steep comprehension curve. Time to first deliverable vesus lets all code like crazy, so it looks like we've done something will be noticeable.

Shifting to TDD on an existing code base? That's all tied up behind shifting to unit testing on an existing code base. That's a a well known issue with some ameliorative techniques that have been round for ages, and basically involves at least some refactoring of the code in order to test it it.

Thing you've got to remeber is none of this stuff is particularly new. It's not bleeding edge technology, doesn't require the worlds top coder ever. The technical and business arguments for any piece of software with a significant longevity are inarguable. Yet most of us have never done it, less of us do it all the time, and noine of us could expect a legacy piece of software to be in a state for TDD.

There's a reason for that, business does not believe in it. Until we address that, we are in the vernacular buggered, constantly and with great vigour....

Smile...