I've done TDD to a variety of degrees on different code bases, with a variety of success. I think when you achieve the right rhythm and approach for your partic

I've done TDD to a variety of degrees on different code bases, with a variety of success. I think when you achieve the right rhythm and approach for your particular code base and team, TDD can make you go faster. If it's not helping you build quality software quicker than you could without it, don't do it. A number of these points aren't familiar to me (trouble finding testing for deleted code? harder to modify tests for changing requirements than start from scratch? Renaming variables is hard?). These comments make me wonder if you've been treating your tests the way you treat your code. When TDD has worked best for me it's because I've spent a lot of time thoughtfully putting some organization into my tests, making sure they're ridiculously fast to write, and ridiculously fast to run. Your source code becomes slave to your tests, that's the whole point. The fact that your tests are in your way, suggests that you're doing it wrong. If you were doing it correctly, and TDD was failing you.. I think the symptom would be your operational code getting in the way instead.