In my experience TDD is great when you know what you want a particular piece of code to do. The other place it works well is code written as a pair - with one

In my experience TDD is great when you know what you want a particular piece of code to do. The other place it works well is code written as a pair - with one member writing tests and the other writing the implementation - the challenge is on to pass the buck back to the other pair member - i.e. find the obvious test that will cause the code to fail / find a simple implementation that will cause the tests to pass. This is great fun and leads to some high-quality code with lots of fast tests. The benefit of TDD is that your coverage is pretty high - and you aren't writing anything unnecessary (YAGNI). I don't think I have ever rewritten tests that I have written (TDD or otherwise). They might get refactored. TDD doesn't work so well when you only vaguely understand what you are trying to do. This is not a coding / testing problem - get a better vision - prototype something perhaps - i.e. no tests and very deliberately throw it away.