Okay, so this is far from what I expected my first post to be. I had many intentions of creating a post about something unrelated to my field, something that would stretch me beyond my comfort zone, something that would really push me as a person, not simply push me as a programmer.

I find myself going the other way with this one. I’m going to do a little write up about the little thread found over here in which there’s a little debate going on. 

Of course, by this time, I’m a little late to the response game, and I’m the furthest thing from an expert to be commenting on this, but I’m going to share my response here because for someone who wants to talk, but is found to be sitting at a table with titans, it’s usually best to just sit back and watch the magic happen, and share it later when returning to the world of men.

The thread itself set the twitter world on fire (okay, my twitter world tends to be limited to the world of software development, as such, it’s probably not your twitter world) in which Bob Martin defends (once again) that TDD (Test Driven Development) is THE correct approach to solving a problem in software engineering.

I would like to say this first and foremost: I see no valid reason that this should even be debated. TDD is a tool, in my belief the tool, that aids in the development of correct, malleable, and maintainable software.

It is true that a developer can create software that is all of these things without following TDD, and many have, but from what I have seen this is limited to people who have a great deal of experience working without it or it comes at an overall sacrifice of time. TDD can save you this time. This does come at a cost. The developer is responsible for actually learning TDD, as with everything, this takes time. On the other hand, programming without TDD also comes at the same cost. To successfully code without TDD and avoid the same pitfalls that TDD helps you avoid takes practice and experience. This time and experience is misplaced. The draw to avoid TDD comes from the initial cost of learning TDD; those with [vast] experience without TDD have their own methods of avoiding these pitfalls, as such the foreseeable benefits are considered insignificant to the initial cost. I have no good argument or debate to put against this. I have neither the experience nor the expertise to counter those that do. What I can say is this: for those developers who, like me, are at the beginnings of their career, who are still trying to properly formulate their skills, who are trying to become more flexible, TDD is in the realm of essential practices.