Recently, fellow Zone Leader Sam Atkinson wrote an article concerning a discussion we had about TDD.
In this article, I will be presenting my defense — and why what Sam has to say is but a narrow view of the world.
I would like to start by saying that I am, indeed, a fan of TDD. In fact, I use it in my own, personal, everyday programming; that is, when I'm the one with tasks to do, TDD is my go-to methodology.
But right away, this is the issue: Looking at Sam's article, it is very "me-centric". His first major point as to why TDD is great is bang on; I couldn't agree more. However, getting to his second point (the lion's share of the article), it is a case of him having used TDD, the challenges he has solved on his own, etc. Now, I'm making a little bit of an assumption (as Sam has about yours truly) that he isn't leading a team of developers of mixed skill levels. This makes it much easier to be a proponent of something when it's just you advocating for and using it.
So, let's now assume that he is, in fact, either leading or working with a team of developers: In the case that they are all of approximately the same skill level, then things can work out nicely with proper coordination and buy-in, especially from the project lead. Even if the developers are of varied skill levels, there is absolutely the chance to train them and get them on board.
This can be a costly proposition, especially if you work in an environment that isn't as solid as, say, a bank. This may be oversimplifying things a tad, but, one needs to consider the world in which methodologies are employed.
Take, for example, a small consulting/contracting firm with unpredictable (not necessarily high) turnover, in a climate where resource pools are thin (hey, we can't all afford to pay a junior developer $90k out of the gates). As anyone who has worked in this type of company can tell you, clients are not interested in paying for developers/teams to learn on their dime. Every hour a resource is not billing is lost revenue for the company.
From my own personal experience (to take it back to Sam's point), I employ TDD when it is appropriate, generally either on projects I am working on myself or on larger projects where I have access to TDD-experienced developers or have at least been able to convince my team to spend some extra (unpaid) time with me outside of work hours to help hone their TDD skills.
In an ideal world, all developers would buy-in to the methodologies used by their shop and be passionate enough to learn and use them. However, in a company where turnover is a reality and everyone is working on multiple projects--including the CTO--with budgets being cut and clients wanting rock-bottom prices, this is not always possible. Call these excuses if you like, but, there are other, hybrid methods that can (and do) work, and this is from more than just five years' of experience of one methodology.
TDD is a wonderful tool to have in any developer's belt. At the very least, unit tests should never be optional--neither should integration tests. However, to say that TDD is always the "best fit" for development is to risk ignoring other factors: Pragmatism sometimes trumps idealism. Things are not always so black and white, and Sam's post, while educational, itself hides behind a narrow view of the development world.
In a world where agile (little "a") practices are increasingly common, it seems a little short-sighted to not consider what other tools may be right for the job given certain conditions. Stating that TDD is a silver bullet is counter to the entire agile spirit, or at least highly ironic. It should be axiomatic that considering your circumstances should and must factor in to any development methodologies that are applied.
And on the off chance that these two posts start a discussion in the comments: Perfect. But given that this subject has been shown before to be a touchy one, let's keep the arguments civil and leave the character assassinations, out, shall we? :)