I think that the issue around (rather than with) TDD is the discovery process of understanding enough about the problem domain. Testing is good, and well designed and crafted tests make it easy to maintain and extend software.
Personally, I find TDD isn't that useful in the early stages of development. I just don't find that I get enough value out of it in exploring a problem domain. What works for me is to explore the problem domain with a sketch of the code - trying different options etc. Once I have a feel for the problem domain, and a feasible solution approach, then I will write tests based on the sketch, with both an understanding of what the desired behaviour is, and some understanding of the constraints and gotchas. Those tests then provide a reference point for a much more TDD based exercise in refactoring, cleaning and extending the code into the finished solution.
I think that the issue around (rather than with) TDD is the discovery process of understanding enough about the problem domain. Testing is good, and well designed and crafted tests make it easy to maintain and extend software.
Personally, I find TDD isn't that useful in the early stages of development. I just don't find that I get enough value out of it in exploring a problem domain. What works for me is to explore the problem domain with a sketch of the code - trying different options etc. Once I have a feel for the problem domain, and a feasible solution approach, then I will write tests based on the sketch, with both an understanding of what the desired behaviour is, and some understanding of the constraints and gotchas. Those tests then provide a reference point for a much more TDD based exercise in refactoring, cleaning and extending the code into the finished solution.
YMMV.