If the existence of working software is validation for a methodology, then plenty of first class software has been and is being written every day without "TDD" of any kind. By your logic that should validate the idea that lack of TDD is helpful.

All I am saying is that extraordinary claims require strong evidence.

also you quote selectively . Norvig goes on to say

"But you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution."

Hardly the ringing endorsement of TDD that you imply. Besides the original article contrasted Norvig's algorithmic insight based approach to Jeffries's
"write tests to try to improve understanding" approach( (at which he fails miserably btw).

In the very article you link to Seibel goes on to say (emphasis mine)

"But he (Jeffries) did choose to tackle this particular problem using TDD, a technique in which he is supposed to be the expert? Why did he have so little success?

One thing I noticed, reading through Jeffries’s blog posts, was that he got fixated on the problem of how to represent a Sudoku board. He immediately started writing tests of the low-level details of a few functions for manipulating a data structure representing the 9×9 Sudoku board and a few functions for getting at the rows, columns, and boxes of the board. (“Boxes” are what Sudoku players call the 3×3 squares subsquares of the 9×9 board.)

Then he basically wandered around for the rest of his five blog postings fiddling with the representation, making it more “object oriented” and then fixing up the tests to work with the new representation and so on until eventually, it seems, he just got bored and gave up, having made only one minor stab at the problem of actually solving puzzles.

I suspect, having done a small amount of TDD myself, that this is actually a pattern that arises when a programmer tries to apply TDD to a problem they just don’t know how to solve.

If I was a high-priced consultant/trainer like Jeffries, I’d probably give this pattern a pithy name like “Going in Circles Means You Don’t Know What You’re Doing”. Because he had no idea how to tackle the real problem, the only kinds of tests he could think of were either the very high-level “the program works” kind which were obviously too much of a leap or low-level tests of nitty-gritty code that is necessary but not at all sufficient for a working solver."

Hmm that doesn't sound like an example of "tdd is a way to deeply understand a domain". Sounds more like "if you are clueless, TDD leads you in circles".

That isn't to say that TDD may not help in specific instances. But hey, paper and pencil, or reading up on the domain, or building a non TDD prototype are likely be much better.

So if you claim that TDD improves domain understanding in any substantial fashion you need stronger evidence or logical reasoning than a truncated selective quote from an article that claims the exact opposite.

All that said, if TDD is your favorite method of sw dev, good for you. I just find claims about it being a tool to "deeply understand the domain" somewhat dubious. Any but the most trivial domains need more than "TDD" to understand (imo).

YMMV. This thread is overlong and so I'll exit with a friendly "adieu", and leave the field to you.