Excellent post, I've had exactly the same experience and come to exactly the same conclusion.
I still follow the old Code Complete method: think about the problem, sketch it out, then finally implement with unit tests. The results are the same, and it's a lot less painful than greenhorn-TDD.
I do this as well. Prototyping needs flexibility and unit tests slow down refactoring. If you are familiar with SOLID then your design will be not bad even without test-first approach.
I completely agree with this. I fact when I have a bigger architectural problem to think about I like to sit on it for a day or two, thinking about one or two designs that would work. It takes a while to see the strengths / flaws in each design and jumping in to code you won't realize problems until you have something half implemented.
Comments
Excellent post, I've had exactly the same experience and come to exactly the same conclusion.
I still follow the old Code Complete method: think about the problem, sketch it out, then finally implement with unit tests. The results are the same, and it's a lot less painful than greenhorn-TDD.
I do this as well. Prototyping needs flexibility and unit tests slow down refactoring. If you are familiar with SOLID then your design will be not bad even without test-first approach.
Time at a white board breaking down a problem is rarely wasted :)
I completely agree with this. I fact when I have a bigger architectural problem to think about I like to sit on it for a day or two, thinking about one or two designs that would work. It takes a while to see the strengths / flaws in each design and jumping in to code you won't realize problems until you have something half implemented.