As a writer, I’ve left a few incomplete efforts by the wayside, promising I would someday return and complete them. The one I feel most guilty about is an interview with a promising young developer named Tim.
In 2006, I had helped train and coach a development team in TDD at a large corporation’s headquarters in the U.S. In fact, the training and coaching were separated by a month or so. I initially worked with a cool manager who brought me in to run training, but by the time I returned for the follow-up coaching, the manager had departed. In his place was a humorless, dictatorial manager. While working with the team, I focused primarily on helping the individuals see how TDD might help them build quality software. Unfortunately the temperament of the manager meant I departed with few hopes for the success of agile or TDD at the team level.
When pairing with Tim, I could tell he was very sharp but also very skeptical and resistant to TDD. Two years later, I received an email from him. He had some interesting things to say. I asked him some questions on TDD, with the intent of shaping it into an interview I would publish. He asked that I not mention the company at that time. Well, four years later, I still think these are wonderful answers, and so I plan on publishing them over a couple or more blog entries. (Tim–sorry I took so long!)
Here’s one of the questions and answers from Tim.
Q #5. What did you finally see or recognize in TDD that you initially couldn’t see?
A. I have somewhat of a loaded answer to this question. I’ll preface with this… I didn’t go out and research TDD on my own. I had never heard of it, or knew what it meant. I wasn’t chomping at the bit to change the way I had been writing code for the 5+ years before that. It was directed from the top down in my organization, and my team was a test bed, so to speak. Right off the bat, I had preconceived notions as to why I had to learn this approach, but why should I? So I had no expectations as to what I was supposed to see other than tangible things that management probably thought were the only byproduct of TDD (i.e. JUnit/HttpUnit test cases).
So I can only answer your question with what I have found with using the TDD approach. It’s rather simple, and yet not so simple. I have to bullet them:
I have found myself writing cleaner, more efficient, maintainable, and better “architected” code.
I have a better understanding on topics as simple and innate as the Java specs, to more complex such as patterns, writing frameworks, and abstraction.
Some would laugh, but I never followed the whole “code to the interface, not the spec” statement. I cannot imagine not following this now.
My skills with the editor I use have become extremely advanced. So much so, that I would challenge anyone who claims TDD will slow you down that I can write the same thing simpler, faster, and tested.
I automatically have a spec/documentation (the test cases) since that’s where I start. Any developer who says they keep up with documentation is flat out lying!
I have more confidence.
I have the feeling of “getting it”.
And I have more fun.
I can admit that I didn’t fully understand TDD until a couple of years ago. So if you do the math, it took @2 years to really sink in, but I know I am better now than I was then (and I thought I was pretty damn good). I can only surmise that in 2 more years, I will feel the same compared to now.
By no means am I saying that I can solve any and every development endeavor and never get frustrated or challenged, all because of TDD. Development is challenging. If I didn’t get challenged than I would probably, really hate my job. I could do without the frustration, but that goes with the territory… and builds character. I feel like I have to say this because (and I think I mentioned it before) some developers I talk to think that TDD is a silver bullet to solve these issues just because you have some test cases and a build server, and as you can see (I feel) it’s much more.
One thing that stands out for me is Tim’s notion that he has “more fun.” More on that in an upcoming post.
Comments
Pingback: TDD: No Fun, No Gain? | langrsoft.com
Pingback: TDD: A Minority Report | langrsoft.com
Frank taught us one great lesson, which is that there are no silver bullets.
