The recent debate over #IsTDDDead is very interesting to me. Not because I believe TDD to actually be dead, but because I think it goes against core beliefs of some software developers, especially for those who practice TDD on a regular basis and has now become integral to how they build software.
Now that the shock of the proclamation that TDD is dead has subsided a little bit, we can start examining the reasons prompting this statement, and maybe incorporate some of these thoughts back into our own views of software development.
But for that to happen, we need to reflect on our own view of the world, and be open to the possibility that some of our views might be wrong. Admitting that we're wrong is something that can be hard to do, especially if its our long standing beliefs that are in question.
I approach software development assuming that there is a better way, but I haven't found it yet. As a result, I'm always in pursuit of a better way.
Who better to learn from than those with decades of experience who publish their tried and true methods. I try to read as many software development books as possible, my favorites being The Pragmatic Programmer, Clean Code, Extreme Programming Explained, and Refactoring: Improving the Design of Existing Code, Domain Driven Design, The Art of Unit Testing, Pragmatic Thinking & Learning, and The Lean Startup.
While I'm not really tied to any specific methodology, I do appreciate the benefits of TDD. Having a suite of tests that you rely on to make the decision to ship or not is very compelling. Being able to Refactor safely is also a nice benefit, especially if you take an incremental approach to evolving your architecture.
The good thing about always assuming there's something your missing is that you never stop learning, and you are open to other peoples opinions and ways of doing things.