The Effectiveness of Test Driven Development

I've always been curious about Test-driven development (TDD). I've been told that it speeds up development time, because you can reduce the amount of bugs hiding in your code. With TDD, you are more likely to find bugs right away, and not months later when it's harder (and more costly) to fix them. Although I agree completely with unit testing as much of your code as possible, I don't think that TDD is the best way to produce these tests. Apparently, I'm not the only one who feels this way, and there is a lot of debate going on in this area.

According to case studies done by Microsoft and IBM, TDD teams took 15-35% more time to develop the applications, but the bug density was reduced by 40-90% compare to more traditional projects. The problem is that some (most?) projects can't afford to delay feature development time by 35%.

The main idea behind test driven development is:

1) Write tests for a feature you are about to implement. These tests should fail at this point.

2) Write the minimum code required to satisfy these tests.

3) Re-factor the code, making sure that none of the tests break.

I think my main objection with TDD is step 2. I don't think writing the minimum code first and then refactoring is a good way to encourage good architecture. At the very least, it's more time consuming than it needs to be.

For me, the final design for something (especially small features) is pretty straight forward, but requires writing "extra" code. That is, I could implement the feature in a simpler way if I wanted to. However, implementing it the "stupid", simple way first, and then refactoring it seems like a waste of time to me.

Perhaps part of the problem is that I've never used TDD in a professional environment. Maybe I'll get a chance to at some point. Until then, I prefer to write my unit tests after my feature is implemented.

What do you guys think about Test driven development?