Exploratory programming is a way of getting to that point, fast. You can bring out the tests when you’ve got a project (or piece of a project) that you’re pretty sure you’ll be using for a while.
There are two problems with this idea. First, I’ve found TDD to be extraordinarily effective at helping break down a problem that I have no idea how to solve. That is, if I don’t even know what to sketch, I sometimes start with the tests. (Test-Driven Development By Example has some good examples of when/why you’d do that.)
Second: we can be really bad at guessing whether or not something will get thrown away. Rarely does version 0 really get thrown away, and so by the time you’ve built up a bunch of code, the odds that you’ll go back and write the tests are negligible.
There are two problems with this idea. First, I’ve found TDD to be extraordinarily effective at helping break down a problem that I have no idea how to solve. That is, if I don’t even know what to sketch, I sometimes start with the tests. (Test-Driven Development By Example has some good examples of when/why you’d do that.)
Second: we can be really bad at guessing whether or not something will get thrown away. Rarely does version 0 really get thrown away, and so by the time you’ve built up a bunch of code, the odds that you’ll go back and write the tests are negligible.
That’s a choice. Some of us deliberately throw away the first draft for anything that matters, no exceptions.