This book annoys me. Firstly, its length annoys me. At a rather short 200-odd pages, it is already far too long. 50 pages would be sufficient to express the concepts if you were being verbose. The initial chunk of the book consists of two incredibly tedious examples. While it could be argued the noddy examples the book uses are pretty much necessary to introduce the ideas cleanly, and the pace is a necessary part of that, the book feels like something almost pamphlet-like blown up to a couple of hundred pages in order to justify a whole book. This is from the same school as Extreme Programming (XP), which, surprise surprise, appeared to use half a dozen books where one could do. The tone of the text might be described as chatty, but 'filler' or 'inane banter' might be more accurate, given the glacial pacing.
Secondly, the depth (or lack thereof) annoys me. Kent Beck is probably a bright chap. He certainly has plenty of experience and can name-drop with the best of them. He seems to like reminiscing about SmallTalk, which is probably a good thing if you want to bring current development practices up to the cutting edge of the '70s (I'm being serious - the wider community is still trying to catch up with '70s SmallTalk in places). However, he writes like an idiot. More specifically, the book is condescendingly simple-minded. While I'm sure simplifying complex topics can be viewed as a sign of intelligence, here it feels like dumbing down and copping out. Having read the SmallTalk-80 coloured books, I'm feeling there's a bit of a pattern; SmallTalk Disease appears to be about simplifying things as much as is valid, and then a little bit more for good measure.
This is not to say the approach is not useful or sensible. As a general concept (expounded more succinctly and less dogmatically than in this book), I rather like it. However, by steering clear of anything challenging, which might show up the strengths and weaknesses of the approach, he removes a certain amount of criticality, and also fails to demonstrate the tricks of industrial-strength real-world usage. It's a sales pamphlet.
So: the test-driven development approach. I only have a few years of development experience, but that won't stop my punditry. The general approach is pretty much what you get if you combine unit testing, incremental development and common sense. However, it doesn't seem to work well with the usual bugbears of automated testing. Network servers and I/O-performing systems are going to have problems, although this can be hacked around by creating faked stubs for the lowest-level I/O primitives. Not that the book discusses this in any detail. On the other hand, TDD is about minimising the fear of having broken code, and while pretty much everything else can be made in baby-steps, switching between stubs and real I/O is going to be a huge jump. What happens if your code breaks switching between the modes? Things like testing graphics rendering algorithms would also be painful. And as for properly testing multi-threaded code? Oh well.
So, ignoring the problems associated with automatic testing, there are other issues. In TDD, you pretend to be stupid. You're forever making small changes and checking they work. Each small change pushes you towards a full working program. It's basically hill-climbing. However, this is disingenuous, as you're probably thinking ahead, planning where your steps will go, but while you're performing these steps you're hiding the plans from yourself. And if you're not doing this, you're going to hit local maxima, and going to spend lots of time undoing your sub-optimal approach. This is rather brought home by the notes in the book about how much the example program's derivation was rewritten in order to produce a really clean looking example of TDD. So, the example lies about how straightforward development is, even when practised by its foremost proponent, and the time spent on what is basically a very simple piece of code rockets up. I know it's all about the presentation, but the whole thing feels painfully contrived and moronically simplistic.
Furthermore, the given approach feels a bit like voodoo. Why create a test your code fails on, and then write code that makes the test pass, in that order? The given reason is that apparently you'll never write the test if you write the code first. Apparently you can be disciplined enough to follow the procedures in this book, but only if they're fed to you in a given order. My guess is that this order is chosen to make it feel more controversial and cutting-edge. Beck says you can choose your own step size when cycling through the TDD approach. For me, I find it a lot easier to write code until I feel there's a chance it might not work, add tests for all the latest code, and then run the tests. It seems rather more difficult to me to plan your step size through writing tests first.
Another thing that worries me is that the focus on incremental change is unlikely to lead to global optimisations. It's a technique for implementing simple things safely. I'm sure you can implement difficult things through small-stepped TDD, but it'll be a party trick of knowing at the start the code you want to end up with, and showing how you can write it incrementally, with tests.
Other things I find odd are the lack of emphasis on automatic tools beyond the test framework. I like coverage testers to make sure my test code is doing a decent amount of testing (yes, I know that braindead use of coverage tools is basically useless, but let's assume you're using them sensibly). Presumably there is a good source control approach to use with TDD. When writing code, I like to leave greppable 'FIXME' notes on any code that's even slightly incomplete, so that it should be impossible to leave any feature partially incomplete (which appears to me to be a real danger when doing TDD: fake something up, forget about it, and fail to write a test that shows up this shortcoming). These are the kinds of topics I find the book falls short on.
To an extent, a dozen page chapter towards the end raises and discusses a few questions about the technique. To a degree, this rescues the book, but it feels like too little, too late. It's not terribly challenging.
On the whole, I like the approach. However, I think a concise, critical and genuinely thoughtful document on the subject would be most useful. This is not it.