I just received the following email that I thought I would share and answer publicly:

“I’m not using this methodology (TDD) because my principal question remains unanswered. I know that with TDD you should release less bugs, but what about the time needed to develop with that methodology ?

I would like to know if the time to develop an enterprise solution is faster, equal, or longer with TDD.

I hope you will be able to answer me because i’m very intrigued and interested by TDD and DDD.”

The first and most important point that I would like to draw attention to  is the misconception that TDD is a tool to ensure that you should release less bugs. Although one side effect of TDD is the fact that you may well end up with a smaller bug count that is not the driving factor behind the adoption and practice of TDD. The driving factor behind TDD is that of driving out the design of components in your system one test at a time.

With respects to the question:

“I would like to know if the time to develop an enterprise solution is faster, equal, or longer with TDD.”

When you first make a decision to head out onto the ski hill and take a shot at snowboarding you head out with a dream in your head of being able to carve it up within minutes and do tricks that would make SSX Tricky look lame. The reality of the situation quickly kicks in once you have fell for your first couple of times and you realize that it is going to take a bit of time before you become proficient enough just to traverse the hill without any glitz and glamour. If you are wise, you will take the time to get instruction from a qualified teacher, who can help you establish good footing and technique from day 1. Building upon this base of solid instruction will ensure that you able to grow as a snowboarder effectively over the next couple of months, and potentially avoid picking up any bad habits you may have formed had you tried to pick up the sport yourself without any instruction.

Like snowboarding (or any new skill you wish to acquire), in the beginning a lot of learning is going to be taking place. For the majority of people who venture into TDD waters, they realize that there are potential big holes in their skillset that may cause them pain in this new world. Assuming that those holes are not there, you will still have to deal with the fact that for the first little while you will be training your brain to tackle and solve programming problems in a way that it is not accustomed to. This is actually one of the biggest hurdles people have to jump when getting into TDD. The development of a new style of coding that forces you to think about a small win and code the API as if it is already there. A good way to start into TDD is to start with state based testing. Once you have got a good handle on state based testing you may mix it up with interaction based testing also.

The fact of the matter is, when you start TDD you may very well end up finding yourself moving ahead at a slower pace than normal, this is predominantly because you will be working out of a comfort zone that does not yet feel natural. When you experience your AHA moment with TDD, it will be shortly after that when you realize that writing the test has now become a natural extension of how you work, you won’t need to account for the fact that you are using TDD to build a project, as it will be melded into the way you function as a developer.

Having witnessed two teams (one agile, one non agile) with developers of the same caliber being asked to deliver functionality on a project. The team that practiced TDD was able to meet the needs and changing requirements in a way that completely surpassed the team that was coding without TDD. I have seen it work on my own projects countless times, projects ranging is size from the small to the large enterprise level. I personally would not be trying to teach people the benefits of TDD if I did not feel it was a justifiable learning to undertake. Speaking for myself, it has completely transformed the way I look at solving problems in the programming realm.

Much like many developers have acquired traits and behaviours with respects to their coding style and how they solve problems, TDD becomes another “natural” trait that becomes part of what you do to solve problems. The first thing you will do when faced with a problem is write a failing test to capture the requirement that you want met.

Ultimately, people have to make a decision to take a walk down TDD avenue and stick with it long enough for it to become something that feels natural. If you don’t give it a good shot, you could walk away not realizing the benefits that TDD can bring to your development arsenal.

For those of you who are looking at TDD as a serious option but have not yet picked it up, this may be a good season to hit the hill!!