I also find TDD to be rather useless when you haven't quite figured out what your architecture is going to be yet. My general process is model -> test -> code.

I also find TDD to be rather useless when you haven't quite figured out what your architecture is going to be yet. My general process is model -> test -> code. If I can't yet determine my model because my knowledge isn't deep enough yet, the tests are all garbage that will have to be rewritten anyway. I get the argument of tests as interface specification, but I just don't buy it. Some people may not like to model outside of code, aka UML or variants, but any reasonably complicated system needs a high-level concept drawn up before you can safely start pushing through individual components. I love TDD for known problem/known solution scenarios, but I've found it to be a pretty bad time sink for unknown solution combinations. YMMV, and I think everyone finds their own comfort zone with TDD after some experimentation. The big lessons for me were that [x] testing is a net time saver versus the spray and pray code like hell strategy (yes, this makes sense before you realize you're not a programming messiah after all!) and that taking the perspective of a code consumer helps you write more fluent APIs.