I think the reason that has generated so much chatter is that jwz's experience goes against a lot of current advocacy--TDD, c++, design patterns. Personally, I think this is a worthwhile discussion.
And this is just from the first chapter. Spoiler: it doesn't really get any better for C++, TDD, IDEs in the rest of the book.
Y'know, I don't like IDEs or C++ much myself, but I have never, ever regretted the time I took to write tests. I'm not a devoted TDD advocate though; sometimes I'll think of tests to write first, sometimes I'll write some code first, but I sure like having those tests there pretty soon after I'm done touching the code for the first time.
I'm gonna keep plugging away at tests until they don't make sense to me any longer no matter who tells me they're not needed.
I've definitely regretted tests. Badly written or ill-conceived tests couple test code to implementation details. On several projects, I've found myself stuck in places where trivial (and necessary) implementation changes necessitated 45+ minutes of test grooming.
Testing is good. Long live tests. But be careful not to let the cart drag the horse.
The principle of test-first also sounds appealing, the idea being to write the test code, and thus end up with an easier to use API.
It depends on the kind of project, how firm the design is, how much rework will be needed, how prototype-y it is, where the architectural divisions will lie => what's the most testable APIs, etc.
Well, few of my tests are regretted, but then I have done lots of stuff without tests and it goes fine. The system I am working on has undergone several major wrenching changes, and would have required discarding a more complete set of tests had they been done.
I am still of two minds on the subject, and look forward to more discussion.
You know, TDD is somewhat controversial, but design-by-numbers GoF patterns aren't: you might as well be busting out UML or the Booch Method. It's a great book to learn a way of thinking about systems, but a discredited methodology (and one that was never actually intended to be a methodology).
Let's be careful about what we lump together here.
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.
More importantly, it is also a question of your toolset and the problem at hand.
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.
Kent Beck said in a recent episode of FLOSS weekly (http://twit.tv/floss87) that he first learned a TDD-like approach to writing code from his dad who programmed in the paper tape-era. Of course it was not called TDD back then.
I read Britcher's "Limits of Software", http://www.amazon.com/Limits-Software-People-Projects-Perspe... , years ago, he also started back in the batch mode era; his take was that having to write everything out first and the slowness of the feedback, resulted in programmers being much more careful and producing fewer bugs in the first place.
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.
