Almost every point for or against TDD in this thread is based on factors that go beyond TDD itself. Many seem to have a bad taste in their mouths from experien

Almost every point for or against TDD in this thread is based on factors that go beyond TDD itself. Many seem to have a bad taste in their mouths from experiencing bad tests, for whatever reason. Often this is a result of programmers who have yet to learn how to write effective, flexible tests. Proper TDD, just like everything in software development, requires experience, dilegence and patience in thinking through the problem space. Developers who are for testing, at least in my experience, tend appreciate the side effects of writing tests; simplified interface code, code base stability on evolving projects and flexibility to change implementation without breaking features. That being said, I agree that for new problem areas, TDD is often a burden. If you're approaching somethin new (a new tool, protocol or external api) it makes a lot of sense to write throw away code until your understanding of the problem domain evolves. At that point, when the problem is understood enough and the feature is to be implemented into a production system, it is appropriate to write a solution using TDD. Ultimately everyone has their preferences and, depending on the problem and situation at hand, it's up to the developer to decide if the long term uncertainty of a code base without TDD is better than a short term gain in productivity. Both approaches are appropriate, given context.