[lgriffith]

I see. TDD works on poorly designed, poorly implemented, basically lousy code. Code that is highly coupled, withlow cohesion, and is inappropriately modularized. This necessitates that all code must be tested every time there is a "modification". Add to that the random unthoughtful modifications made by careless programmers who have identified the wrong problem to fix and you get constant disaster.

I say, fix the fundamental problem by not writing lousy code in the first place. THAT would really be adding value rather than simply adding job security busy work. Automated testing cannot fix lousy code. Most of the time, it can't even discover it.

There is no magical way that gets good results without knowledge, skill, understanding, thought, discipline, and effort. With those things, all you need are good enough tools. TDD may be one of those good enough tools in some limited circumstances. It is not a Silver Bullet that cures all, most, or even many software flaws.

Keep in mind that one really good programmer can out produce a team of twenty poor programmers. Also keep in mind that one poor programmer can keep twenty really good programmers busy cleaning up the trash they create.

TDD is a very poor band aid used to cover up an even more fundamental problem: most programmers are lousy at programming. That is the problem that need fixing.

[teej]

TDD is like bumper lanes at a bowling alley. If your goal is to knock down the pins, it can help prevent problems, like falling in the gutter.

Of course, if you're incredibly good, you don't need the bumpers. You might even forego bumpers to show off that you are -that good-.

Your solution is to make all the bowlers really good. Here's the issue - historically, that doesn't scale across a growing dev team.

Imagine 5+ bowlers all using the same lane. The more bowlers you have, the more you will have balls bumping into each other, getting in the way, crossing paths, and falling into the gutter.

As you increase the number of developers, the more likely it is that tools like TDD and Source Control can help mitigate issues that inevitably arise on a larger team. They aren't silver bullets to great programming, and they aren't a bandaid to cover up bad programming. They are time-tested, proven ways to get people going the right direction.

[lgriffith]

"Imagine 5+ bowlers all using the same lane. The more bowlers you have, the more you will have balls bumping into each other, getting in the way, crossing paths, and falling into the gutter."

I suggest THAT is the problem. TDD is a band aid to cover the fact that such a team cannot function. The right team of <=4 can blow the roof off of ANY team of 5+ based upon communication network overhead alone. If you don't have the right team, you are hosed no matter what.