Getting over the TDD hump

Chad mentioned that the first 2 hours of TDD are the hardest. Without a good pair by your side, the pain can stretch well beyond a couple of hours. Maybe I had a rare experience, but my first experience with TDD was successful and had very few bumps. Looking back, I don’t know what exactly we did right, but maybe the whole story might put things in focus.

I had read a lot on blogs about TDD, but let’s be honest. Blogs are great about focusing on a single topic, or a short introduction, but they don’t pull everything together in a single physical medium. There are very few writers quite as clear and concise as Kent Beck, the author of the original book. So if you hear any arguments about what TDD is, check out the original source. It’s very clearly defined. Without reading Kent Beck’s book, we were merely guessing on what TDD actually looked like.

Step 2: Team buy-in

Many of us in the team looked at XP and liked its values, principles and practices. Another Kent Beck book laid out in clear terms what some good values are, and the value of agreeing on values. Teams have values, implicit, de facto, or explicit. Our team agreed to have some explicit values (feedback, communication, courage, etc.) and take time on regular occasions to reflect on whether we adhered to our values.

We were pretty lucky that everyone on our team had an open mind, but then again, that’s who we tried to hire. We valued passion and open-mindedness to years of experience. And in that case, we were successful. Everyone agreed to try TDD, but no one mandated it. We all agreed that people had success with it and we were capable of success, so there was really nothing stopping each of us from trying except for fear. That’s where our “courage” value kicked in.

Step 3: A gentle introduction

We would have seriously crashed and burned if we tried to introduce ourselves to TDD against our existing legacy codebase. Nothing in our existing product was testable by any stretch of the imagination, and it seemed like that if we wanted to sneeze we needed the database up. In Kent Beck’s book, he introduces TDD in a pairing session tackling a simple problem, a bowling game.

Our team agreed to do something similar, and practice TDD on a simple problem. We decided the board game, “Connect Four” had simple enough rules for us to complete the game in a day. There were no rules for our practice except:

We must program in pairs

Code must be written test-first

We had no constraints on the interface of the game. My pair decided to use arrays and console output for the game, while other pairs went for a visual, WinForms experience.

At the end of the day, we got back together for a retrospective and compared code and tests. We also talked about what went well and didn’t go well, and what we could have done better. Finally, we all agreed we had a lot of fun doing it and wanted to have that much fun developing against our real-life codebase.

And they’re off

The bell sounded and the horses were out of the gates. From that point forward, the bulk of our work was done test-first style. We weren’t great at first, but that wasn’t the point. We had committed as a team to give TDD a fair shot, and our codebase thanked us for it. When we started, we had zero unit tests and we ended a year later with well over a thousand. At first we would have little “woo hoos” when we hit milestones at the hundreds. As our velocity increased, we only celebrated hitting 1000.

Along the way, we had many questions answered simply through practice. We tried different styles, stumbled through many smells. Through our dedication to constant feedback and communication, we drove through any barriers we had. If there was a wrong way to do things, we found it.

But since we committed as a team to work together to improve ourselves (and deliver more value more often), the journey was far easier than it would have been flying solo.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.

This is indeed very important. I’ve been in situations where TDD was *mandated* on people and it just never turns out good. People get bitter because they feel like they’re being forced to start using something that hasn’t been proven in their own minds. Having those “ah ha!” moments for yourself are invaluable when making a paradigm shift such as TDD. Being open enough as a team to give TDD an honest shot along with a good dose of peer to peer mentoring is definitely the best way to approach anything new like TDD.

My experience was a bit different in that I started learning TDD about 5 years ago when I was a sole developer at a cushy corporate job. But I was immediately infected and haven’t turned back since. Although I have learned (and unlearned) lots of aspects of TDD over the years.

Thanks Jimmy. Always great to hear how others approach the introduction of something new like this into a team/organization.

Ads

About Me

I'm the chief architect at Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.