Nor does the emergence of a new design methodology preferred by some programmers in some situations, in itself serve as a reason to dismiss older processes out-of-hand as "flawed" and the new process as "better".
There's a big difference between telling someone, "the code you're delivering is not meeting objectively-decided maintainability goals for this project", and micromanaging the personal workflow which someone uses to acheive these goals (test first, test soon after, use TDD as your primary deisgn methodology vs use whatever design methodology has worked for you in the past).
Trying to do the latter, especially when it's done with a tone of superiority and "you're doing it wrong", I think sums up why TDD advocates often tend to rub people up the wrong way -- especially experienced programmers.
It is, however, a reason to dismiss arguments that everybody would have to use the newer process. Besides, it is not really clear whether "TDD" is superior to older processes.
There's a big difference between telling someone, "the code you're delivering is not meeting objectively-decided maintainability goals for this project", and micromanaging the personal workflow which someone uses to acheive these goals (test first, test soon after, use TDD as your primary deisgn methodology vs use whatever design methodology has worked for you in the past).
Trying to do the latter, especially when it's done with a tone of superiority and "you're doing it wrong", I think sums up why TDD advocates often tend to rub people up the wrong way -- especially experienced programmers.