I consider TDD as a tool rather than a methodology. Its utility is in exploration, when the problem at hand does not have a precedent or an already well-fitting

I consider TDD as a tool rather than a methodology. Its utility is in exploration, when the problem at hand does not have a precedent or an already well-fitting solution. Writing tests first serves more like a guidance in fleshing out the approach. At the conclusion, seeing the 'emerged' approach, I always get an itchy feeling that it could be done smoother, now that I know it's doing what I need. Sure, no one is going to rewrite it, so it goes out as done. The net result is perhaps more domain knowledge, and the tests flesh out the expectations of the behavior. That's why writing meaningful tests (even by the name) make TDD worthwhile. But all in all TDD a kinda prototyping tool first. Ideally, someone has to analyze the bulk of the tests to better formulate the product and its resulting 'spec' such that this prototype could be further maintained, hopefully morphing into a better one at some future time.