> I think we agree more than we disagree. I think so. > However, if you're making a program to solve a problem which is novel to you, it makes more sense to w

> I think we agree more than we disagree. I think so. > However, if you're making a program to solve a problem which is novel to you, it makes more sense to write the tests after you have a solution, since it's likely that your first few attempts to solve the problem will have to be heavily refactored before you have something that works in the way that you want. I slightly disagree. I am happy to put down my purity hammer and spike away happily for a while until I feel I understand the problem well enough. Sometimes long enough to call it a prototype. Then I go back and TDD my way back. The mix, as you note, varies by project. I work in R&D. Some work is more Research, some is more Development. But ultimately some of my work is meant to improve someone's life. One of the ways I satisfy myself that I did a workable job is the tests, and for me at least, writing the tests first achieves that end more effectively. Incremental test-last development works about as well in the small studies as test-first, IIRC. My suspicion is that a non-zero part of the benefit of TDD is that it disciplines you to write a lot of tests. It's a second-order effect that delivers the first-order value.