There are classes of problems for which TDD is quite difficult. My favourite example is fizz buzz. Asking someone to TDD fizz buzz in a job interview is cruel

There are classes of problems for which TDD is quite difficult. My favourite example is fizz buzz. Asking someone to TDD fizz buzz in a job interview is cruel and unusual punishment because it is super hard to do. The reason it's hard for fizz buzz is because it is an infinite sequence. You end up with this choice of either testing some random examples, which may or may not help you with the actual problem (i.e., we can test fizz buzz of 1, 3, 5, and 15, but have we actually said anything about the other ones), or we end up writing tests that are exactly the same as the production code. A sudoku solver falls into this same category because constraints on the rules are global and the number of combinations are near infinite. So you either write some mostly useless smoke tests or you figure out all the constraints and compare the production code to the test code using the same implementation -- which is useless. This doesn't mean it is impossible to test drive these kinds of problems. It's not. But you have to take a very different approach than you would with a more normal problem. Jeffries's mistake was in not realising that his approach would not work. It is entirely possible that he did not realise that there were some problems for which this approach would not work until he tried it. While these kinds of problems show up frequently in some domains, then don't show up at all in others. He may have never run into it before. I highly recommend taking a look at this talk by Kevlin Henney (the TDD discussion starts at 29:15 but the whole talk is worth watching. If you are really pressed for time, his approach for testing fizz buzz starts at 37:40). https://www.youtube.com/watch?v=_M4o0ExLQCs https://www.youtube.com/watch?v=_M4o0ExLQCs I think the thing that's important to realise is that TDD is an approach that has benefits. The benefit of "I can turn my mind off and suddenly the answer will appear" is not one of the benefits. I don't think TDD makes coding easier per se. In fact, I find that junior developers have a lot harder time doing TDD than not doing TDD. It's an added constraint, so it shouldn't be surprising that it's harder. The question is whether or not the constraint leads to other benefits. One of the things I will quibble with you a bit is on whether or not TDD ties you into architectural decision. I do not agree that it should, but I do agree that a very large number of people who believe they are doing good TDD are doing exactly what you say. I have even seen people go off TDD for exactly this reason. However, I will argue that if you see this problem, it's the first clue that you are not doing TDD well. Should you avoid TDD if you aren't doing it well? That's a good question.