I think I am a good programmer, and I think TDD is aweful. Using unit testing, has its place, especially when working with parts that have clear input/output ranges, or in large systems, where your piece of code has to be integrated somewhere else, so you want to make sure it works before committing it.

BUT, programming according to Tests, is not a good idea. Tests are not the END RESULT, not the ultimate user of your code!!! Instead of tests being for what they are: testing your input/output, they are being used to design systems. So, you are designing your programs according to tests, and not their ultimate functionality.

Here is another thing that I think: Weaker programmers prefer TDD. It is like they want validation b/c they are unsure of what they are writing.

I try to write lapidary code, but sometimes it includes arbitrary personal choices. Also, there are times when I can't find a way to avoid combining ideas that I'd like to express separately: maybe I'm doing a performance optimization, or maybe I'm balancing different strata of abstraction. Those are times when it's great to have tests that describe what's essential about my code-under-test. The test assertions can be automatically checked, and they're expressed in formal language.

TDD certainly is a good way to help beginners gain confidence and improve their skills. And, I don't see what's so bad about a stronger programmer who chooses to start with the sparse essence of a program rather than building dense stand-alone code at the beginning. Especially if you're already committed to having tests for qc purposes or as a sort of compromised form of literate programming.

Working on large and complex application becomes near impossible without extensive unit test coverage.

If you're using unit test of all things to guide the design of your application, you are off the deep end. That makes you a bad programmer, it doesn't make TDD bad.

Part of the problem in discussions like these is that people aren't really clear whether they're complaining about testing or TDD in particular, whether they're arguing about the benefits of TDD specifically, unit testing, or testing in general, and everybody involved may read the wrong thing into any ambiguity.

I, for one, would not argue with unit testing (particularly for libraries) or regression testing, but I think that an insistence on TDD can be excessive.

That's a good point, I often catch myself conflating TDD with general unit testing.

I definitely ascribe to TDBF (Test-Driven Bug Fixing) more than TDD - if a bug shows up in my production code, adding a test to the suite to make sure that bug never comes back gives me a great deal of peace of mind. And it helps if I have enough of a testing framework from initial development (such as data and mock object setup) to add new tests quickly. But I definitely don't do enough testing for it to qualify as TDD.

Oh, yes, absolutely. I think few people would argue with that, though they may not have formally articulated it as "having a test framework". (To my understanding, what you're referring to as "TDBF" is more commonly called "regression testing".)

As is often the case, most arguments are about extreme positions.

The utility of TDD varies tremendously from one language to another. Its biggest advocacy is usually associated with dynamically-typed languages, such as Ruby, Python, and Smalltalk, because TDD is a great workaround for mistakes that can easily occur in those languages. That doesn't mean it's a panacea for all programmers, though. For example, the type systems in OCaml and Haskell are effective for automatically verifying many of the same conditions. (Testing is used within those languages, but very differently -- Comparing TDD to Haskell's QuickCheck may prove enlightening.)

Some day, better tools than the type systems in OCaml and Haskell and TDD will be invented. Let's not get so hung up on either as a solution that we miss out on even better ones (or fail to invent them).