But how could, lets say, demanding TDD ever cost you talented programmers? It won't, ever.
This is wrong. TDD may or may not be useful. I'll give it the benefit of the doubt, but in my experience it has been used in a "cargo cult" approach to programming. The last startup I spent significant time at was eventually destroyed because they hired an "Agile/VP" of engineering. He then hired a bunch of guys who could do "TDD" but didn't actually know how to write software.
But that's not because of TDD, it because of people who couldn't write software.
Imagine if those people were also bad at math, would you say math is only occasionally useful?
Obviously I agree about "cargo cult" programming, the worst of it is when someone has a religious affinity for pair programming, but thinks testing is a waste of time.
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).
Your remarks about pair programming may be true. However, I have trouble believing this makes it a poor advertisement. Consider a hypothetical expert programmer who like pair programming but hates Ruby. Such a person could easily say what you just said.
And I know one fellow--who lives in Canada--who might not care to relocate his family to Jacksonville. He could easily write what you just wrote, this time about the fact that the offices are in Jacksonville.
All of these things--pair programming, Ruby, Jacksonville--are going to cut down the number of talented programmers who want to work for Hashrocket.
Given some set of working conditions, I believe the OP does a good job of explaining why the advertisement does an excellent job of attracting the kind of people who would be interested in working for Hashrocket.
The people who don't like pair programming, ruby, or Jacksonville are not the "market" for the ad.
I am a true believer in TTD, continuous integration and weekly team based code reviews, but pair-programming is crap.
Plus, A LOT of very good developers who also love TDD and a lot of Agile/XP practices feel the same way about forced pair programming.
Demanding it is a good way to lose a lot of great talent. But how could, lets say, demanding TDD ever cost you talented programmers? It won't, ever.
There's a lot of great stuff in Agile/XP (that's also in the Mythical Man Month), but don't drown in the cool-aid.