I stumbled across this blog post by Brian Harry:
Programming Practices: Part 2 – Thoughts on TDD
As I’ve dug into unit testing much more in the past several months, something hasn’t really sat right with me about TDD and Brian, I think, hit the nail on the head. I pretty much completely agree with what he wrote – although, I would add a caveat. Rarely do I write code where I know what the final product is, where I just have "work" to do. In other words, where the architecture is clear and it’s simply a matter of physically typing the code – that’s not typical for me. However, in those cases I imagine TDD would probably be fine.
For me though, I typically brainstorm through the beginning of a project because I’m not sure how I’m going to implement it, at first. I find that I will refactor like crazy until I find the right pattern. I too, like to then go back and back-fill the unit tests, once the design is semi-stable.
Now, you might say "Well, there’s yer problem!" – because I clearly don’t work out the architecture on paper, first. So, in theory, I’m wasting time doing actual coding where I could instead work out the architecture on paper… which leads us back to the original thought of "TDD is probably fine if the architecture is already worked out".
So, what’s the right answer? I don’t know, I find that I am quite efficient at working out a prototype of an idea with real code, instead of Visio – but that’s just me. So maybe there isn’t one perfect answer? Maybe TDD is another "tool in the toolbox"? I mean, we all hear the same engineering principles touted over and over, that we’re supposed to spend all our time up-front on the paperwork and design artifacts, and only touch code once we have that nailed down.
Despite that, my experience and most of my career has had projects with much more success, agility, and adaptabaility when I don’t do that. In fact, in the projects where there has been a lot of rigor and paperwork, those are the times where the paperwork didn’t match reality – so the extra time was spent getting the documentation to match what we really implemented. So, is it just a matter of what you want to spend you time on: re-writing the design docs or re-factoring code?
Anyhow – he had a pretty interesting blog post on TDD, if interested… (by the by, I just installed VS2010 with not a SINGLE problem!! Downloading and installing TFS now)