It is just that people don't get that methodologies are just rules of thumb. They are not laws.
There are people that will develop wonderful code using TDD, while others will do the same without it. It is a matter of skill and personal preferences.
There are people that will develop wonderful code using TDD, while others will do the same without it. It is a matter of skill and personal preferences.
If you're a Ruby programmer, and especially if you're a web developer using Ruby, TDD may well save you time, depending on your style: There is a lot of testing infrastructure, a culture, a bunch of blog posts, a language with flexible syntax, and -- in the case of Rails -- a framework designed with the intent of supporting testing.
Whereas I can't imagine that the average C programmer has an easy time adopting TDD. Surely you don't write unit tests in C? That sounds like hell. But if not you have to learn some other language, and write your tests, and integrate them with your build system. And no matter what you do, every build takes a certain minimum amount of compile time and link time... That might be pretty fast in these enlightened days of multicore processors, but let's just say that I'm not surprised that (e.g.) Jamie Zawinski didn't invent TDD for C in the early 1990s. He'd still be waiting for his test suite to run.
TDD is a necessarily new invention. Imagine trying to explain it to the punch-card coders of the 1960s, when computer time was a precious resource that you signed up for an hour at a time in advance, perhaps days in advance. Those folks sweated blood over every line of code, trying to find and fix the bugs before it ever ran. The idea of deliberately breaking your code and then fixing it, over and over, would have been crazy.
ADDED: This actually ties in a bit with http://news.ycombinator.com/item?id=846579 , "Working Hard is Overrated" and James Watson. I have a quote from Watson that I made into a poster back 25 years ago, "Never confuse hard work with hard thinking". Britcher's and to an extent, though they never made it explicit so I might be wrong, Joel's and Zawinski's view might be to think hard about what you are doing while you are doing it. This would also fit in with Joel's final claim that most people can't do successful duct-tape programming, because they just aren't good enough.