I recently read this post by Jeff Langr and really appreciated the comments made by his previous co-worker, Tim. Tim clearly was not sold on TDD right from the beginning, but his comments, after being encouraged to do it for two years, are insightful.
In the article Jeff asks Tim, "What did you finally see or recognize in TDD that you initially couldn’t see?" The bullet list of reasons why he likes TDD very closely matches my own list. I also find it interesting that Tim concludes his findings with the statement that TDD is not a silver bullet when he is clearly a full-on advocate of TDD. But it is true what he says, writing software is challenging, even with TDD. In fact, for a while when you are learning TDD, TDD itself can be very frustrating.
Tim mentions in his response to Jeff that it took about 2 years for it to really sink in. I can echo that statement as it seems the same for me. But, I would like to clarify that I was able to write fairly decent tests after a couple of months and was able to do TDD fairly well within a few months, but it really does take about 2 years before you really gain that confidence about TDD where you feel like you really "get it".
Alistair Cockburn talks in some of his books and in this post about the three different levels of learning referred to as Shu, Ha, Ri. He talks about how, when we are learning new skills, we all pass through these three levels of learning.
During the Shu phase we are building our technical knowledge. We are trying to learn the rules that define the skill and we find it very frustrating when someone breaks those rules because it is difficult for us to understand why we would in this case but not in another.
During the Ha phase, we begin to reflect on what we have learned in the Shu phase. Everything we have learned so far has been committed to "muscle memory", as Cockburn states it, and we can now begin to "reason about the background behind these techniques".
In the Ri phase, the student has mastered the skill at such a level that he can begin to "think originally" about the skill and produce new and better forms of the practice.
It seems to me that TDD has an incredibly long Shu phase. And, with TDD, I think there is a phase, which lasts about 2 months, that predates the Shu phase. A phase which could be aptly labeled the, "what sort of voodoo magic is this crap?" phase. For some of us our heads just spin for about 2 months during this phase. But then, we begin to grasp the basics and we are fully into the Shu phase where we can look at other code samples and reproduce the same effect in the code we are trying to test.
It does seem that we stay in this phase for quite a while, probably around 1-2 years until we begin to really feel we understand and champion the reasons why we are doing it. Perhaps this is why some teams struggle with picking up TDD, especially if they don't have someone who is already in the Ha or Ri phase to help them along.
So it is true that TDD is not a silver bullet, if what you're hoping for is something that makes software development easy (which is not to say it doesn't make it easier). Writing software is complex and sometimes frustratingly difficult even when done right. But I agree with Tim: it makes software more maintainable, cleaner and better architected; it makes writing software faster; it gives me more confidence; and it is more fun to write code with TDD. If your team is just starting to experiment with TDD, stick with it even if it seems foreign and more difficult at first. In the end, I hope you'll find what Tim and I have found...once you get it, you love it.
