The problem with TDD for custom development

I had an idea for a cool app today. I wrote up the initial set of requirements, and came up with the high level "here's how the guts will work" to convince myself it can be done, and naturally started thinking of the architecture.

Soon as I had enough of the pieces "working" in my head, I thought "well  great, let's write some code. But maybe I should do it the TDD way. Hmmm..."

Here's the problem: TDD tools don't exist for what I'm trying to do. Its not a webapp, and it most probably is not in Ruby or Java. Or maybe I should write it in one of those languages then? I dont know.

My point is that TDD is probably not appropriate when you're still doing exploratory architecting of the application itself. You want to see the core pieces work, or you want to figure out what the core pieces even are, TDD will get in the way for one or both of two reasons:

• You'll get hung up on the specification and miss out the architecting
• You'll put your actual project on hold while you build out the TDD tools :)

Now TDD purists would say the specification will extract the architecture or clarify it, but IMO TDD is at its best when the second D implies automation.

As I've been writing this, I'm thinking there's another alternative: Plan for TDD - decide when you'll start doing it and with what tools, and which parts of the app are appropriate to use it for - but dont do it just yet until you know the architecture itself.