Tim Bray has a good post about "Test-Driven Heresy," in which he admits failing to live up to the ideal of writing tests firsts and only writing enough code to pass a test.
I'm Catholic in my test-driven beliefs, which is to say that I am a terrible sinner, but I like to think that I can be forgiven if I just confess my lapses. They are many and varied and far out-strip my actual adherence to test-driven development. The spirit is strong, though.
Why is it so hard, even for believers, to keep things test-driven (or even test-in-the-passenger-seat-but-navigating)? Bray points out that when you're writing prototype / spike code, it's difficult to write tests because (a) part of prototyping is being wildly wrong in your expectations and (b) when the codebase is very small, the effort of separating concerns is relatively high.
I agree. To make sinning easier still, it is also the case that refactoring towards test-driven is difficult with large, "ball of mud" codebases (exactly the ones that would most benefit).
So there's a "window" in which initiating test-driven development is relatively easy. Unfortunately, that window is not a very large part of a software code-base's lifetime.
