I never really understood how TDD can make software better, except for one thing: it forces people to write tests. But that's just a discipline thing: tests are boring and development is fun, you have to deserve your fun by doing the boring part first.
It also makes cutting corners more difficult, because it is possible to have (sort of) working software without testing, but you can't have working software if the only thing you have are failing tests (the important first step in TDD). Most TDD people probably thing of that as a positive, I don't. Sometimes, cutting corners is the right thing to do, sometimes, you actually need to write the code to see if it is viable, and if it is not, well, you wasted both the tests and the code, not just the code.
But I don't think it is the only problem with TDD. The main problem, I think, is right there in the name "test driven". With a few exceptions, tests shouldn't drive development, the user needs should. Test driven development essentially means: write tests based on the users need, and then write code based on the tests. It means that if your tests are wrong and your code passes the tests, the code will be wrong, 100% chance, and you won't notice because by focusing on the tests, you lost track of the user needs. It is an extra level of indirection, and things get lost in translation.
Another issue I have noticed personally: it can make you write code no one understands, not even yourself. For example, your function is supposed to returned a number, but after testing, you notice that are always off by +1, the solution: easy, subtract 1 to the final value. Why? dunno, it passes the tests, it may even work, but no one understands, and it may bite you later. Should I work like that? Of course not, but this is a behavior that is encouraged by the rapid feedback loop that TDD permits. I speak from experience, I wrote some of my worst code using that method.
If you want an analogy of why I am not a fan of TDD: if you are a teacher and give your students the test answers before you start your lesson, most will probably just study the test and not the lesson, and as a consequence they will most likely end up with good grades but poor understanding of the subject.
It also makes cutting corners more difficult, because it is possible to have (sort of) working software without testing, but you can't have working software if the only thing you have are failing tests (the important first step in TDD). Most TDD people probably thing of that as a positive, I don't. Sometimes, cutting corners is the right thing to do, sometimes, you actually need to write the code to see if it is viable, and if it is not, well, you wasted both the tests and the code, not just the code.
But I don't think it is the only problem with TDD. The main problem, I think, is right there in the name "test driven". With a few exceptions, tests shouldn't drive development, the user needs should. Test driven development essentially means: write tests based on the users need, and then write code based on the tests. It means that if your tests are wrong and your code passes the tests, the code will be wrong, 100% chance, and you won't notice because by focusing on the tests, you lost track of the user needs. It is an extra level of indirection, and things get lost in translation.
Another issue I have noticed personally: it can make you write code no one understands, not even yourself. For example, your function is supposed to returned a number, but after testing, you notice that are always off by +1, the solution: easy, subtract 1 to the final value. Why? dunno, it passes the tests, it may even work, but no one understands, and it may bite you later. Should I work like that? Of course not, but this is a behavior that is encouraged by the rapid feedback loop that TDD permits. I speak from experience, I wrote some of my worst code using that method.
If you want an analogy of why I am not a fan of TDD: if you are a teacher and give your students the test answers before you start your lesson, most will probably just study the test and not the lesson, and as a consequence they will most likely end up with good grades but poor understanding of the subject.