Sounds like taking all the fun out of it. I guess TDD is ok if you have a boring clear idea of what code monkey thing needs churning out, but if you're just exploring, playing around and experimenting with what can be done with a tight development cycle I don't see how TDD can really work.
It's like the kid who draws out and designs all his lego creations before he touches any lego, as opposed to the kids that just play around trying cool stuff.
I think you can have the best of both worlds. I tend to do exploratory programming to make a "rough draft", and I've found TDD in this context to be rather stultifying. But, once you've scoped out the project, TDD is great for the process of rewriting/revision.
N.B. I'm currently experimenting with Behavior Driven Development using Rspec. It looks like it may be flexible enough to be used even for exploratory programming, especially since it adds tests for pending features to the usual pass/fail dichotomy.
Tests are obviously an important part of software development. The first thing I wrote once I got Hecl running was a simple test suite. However... I got it running first - I played around, I tried a few things, then I sat down and wrote the code that defined how it should be. When adding new features, sometimes I know exactly what should happen, so I'll write a test. Other times, I don't know how it should work, and need to experiment some, to see how different things would work out in practice. In those cases writing tests first is a waste of time.
I think it's important to note the difference between hacking for fun and trying to eliminate risk in a software project. Those two will often necessitate vastly different approaches.
To quote the classic: "During their operations they seem to focus entirely on the process, but very little on the quality of the code. Sorry guys, but having a 1:4 code:test ratio is not focusing on code quality. It's focusing on test quality."[http://zedshaw.com/rants/rails_is_a_ghetto.html]
This article is exactly right if you have a concrete functional spec of what the code is supposed to do. It's advantages become crystal clear when you have multiple developers on the same codebase and are coding in a lower-level language. It is mechanistic and dull but it works.
Sounds like taking all the fun out of it. I guess TDD is ok if you have a boring clear idea of what code monkey thing needs churning out, but if you're just exploring, playing around and experimenting with what can be done with a tight development cycle I don't see how TDD can really work.
It's like the kid who draws out and designs all his lego creations before he touches any lego, as opposed to the kids that just play around trying cool stuff.