And that is exactly what is wrong with TDD - the sheer dogma involved in a insane statement like that. Throw out all the code - tests weren't written first!

It doesn't seem to matter much that the end result will be the same if you write up some tests for that code, or if you throw the code out, write tests, then just write the same code again. If the tests didn't come first, it's not TDD, and now we can't follow some holy procedure.

Pure madness and everything that is wrong with TDD is summed up in that simple statement: "In TDD you would throw it away and redo it".

I am not a TDD advocate. As it tends to be too cost intense in early stage startups.

But if you are working on critical parts or products you know will be in use for a longer time it is usually the right approach.

To defend why you should throw spike results away in TDD:

- Usually during a spike you learn how to use an api/framework. You are focusing on very low level solutions.

- You made it work the first time. But now when you do it again you wouldn't do it the same way. You don't redo usually.

- Usually the second time the solution is clean and proper strcutured.

TDD is very focused around proper software design. And for the areas where you actually need that it is a great tool.

In any development, you probably want to throw away your exploratory prototyping - that's not TDD specific. I've seen/heard "write it; throw it away; rewrite it" attributed to Knuth on several occasions, but I'm not finding the original source.