Regarding the overhead of TDD, it may seem like slower when you have just started writing the program ("What! You started already an hour ago and have produced just this few lines of code!?"), but then when you take into account that with TDD barely any time is wasted in debugging and hunting bugs, in the long run using TDD is faster than not using it. I'm not sure where the flipping point is, but for myself I'm guessing it to be around 2-5 hours. Writing code with TDD might look slower, but that's because the code being produced is of higher quality. And the speed stays about the same even after the project gets bigger (unlike when coding without tests).

But as with any new practice, there is some overhead to learning it. You need to practice it so much that you can call it "your own". I've written a TDD tutorial to help others get started.

When I started using TDD, writing the first test in a new project took over 2 hours (I was just staring at the blank project, trying to figure out where to start), it took about 2 days to get comfortable with writing tests first (although still occasionally forgetting to), and the quality of the tests I wrote was not very high. That first project lasted about a bit over 40 hours, over a period of 2 weeks. In my second TDD project, which lasted 30-40 hours, I measured how many lines of production code I produced per hour (not a very good measure, I know) and compared it to my earlier LOC/h measures - I was producing production code at about the same speed (~20 LOC/h) as before using TDD, when debugging etc. are taken into count. So in my case there was no overhead after 2 weeks of practice. Now, after 3 years, my performance and output quality are much better, and I'm still learning new tricks.