There has been a lot of discussion about post-Agile, pliant, ex-Agile, etc. It's kind of interesting to see how quickly people jump off of a bandwagon. I shouldn't bitch; most of these people were probably in fact never quite on the bandwagon. I still think this is a great philosophy... but somehow I never quite managed to consistently sit down and write tests first. But I couldn't put my finger on the reason...

Cockburn nailed it when he wrote Characterizing people as non-linear, first-order components in software development 6 years ago (credit to Eugene Kaganovich for pointing it out on Lydor Wyssocky's post).

(If I recall, the Crystal Clear book is in part an elaboration of these ideas, but this essay is a brief, accessible presentation.)

Some interesting points:
People are inconsistent. Most processes do not allow for inconsistencies. This is, I believe, the plain and simple reason why people are frustrated by Test-Driven Development. (No, this is not Cockburn's point; remember this is 2006. Pre-Post-Agile. Pre-Agile, even. But it relates. Bear with me.) When done well, Test-Driven Development works incredibly well... when applied inconsistently it still has some benefit but does not deliver the strong guarantee that it was sold with. As a high-discipline practice, many developers I have worked with would not find it to be an easy or foolproof transition.

The other point I found interesting was the common theme on successful projects that a few good people stepped in at key moments. The idea is that "low precision" artifacts are good enough for most purposes because people in general are "good at looking around". These are not terms that will help sell his methodology. Management does not tend to like "low precision" documentation. And yet, this is what the real world looks like, in my corner at least. And I do have to say, my corner of it does work.

To wrap up, I buy that low-precision docs are good enough, because only code doesn't lie, and I think that could combine well with most Agile principles fairly easily.

Test-Driven Development, on the other hand, is very much a high-discipline practice. Clearly it's a practice which provides a lot of value. But it's also a practice that takes a very serious, disciplined investment in training and maintenance. One that may not be appropriate for every project.

Having already persuasively made the case that we don't actually need specs which detail every potential combination of events, is it possible that we don't need them encoded as tests either? Is low-precision test-driven development the next reasonable attempt to tame software? An instant Sanity Check, rather than a detailed specification of every possible combination of events?