The TDD Session at DevLink – Anatomy of a Train Wreck

If you paid attention to #DevLink on Twitter, you already know about the lunch session on TDD. If not, here is a brief synopsis of the events, taken from the eyes of one of the participants.

It is not my goal to point fingers here or to try to get all of the events documented. I, instead, would like to show how a train wreck happens with the hope you can notice the signs and avoid one.

How This All Began

I was not involved in the beginning of the TDD session. It was incubated in an Open Spaces session I was not participating in. I was in a Open Spaces session on SOA, run by James Bender,  and only heard of the TDD lunch session when Alan Stevens joined in at the end of our session.

It is my understanding that Michael Woods was talking to a fellow DevLinker (is it okay to use DevLink in this manner?) about TDD. The idea, at that time, was to have five or six guys around a laptop talking about TDD to show the value. I am not sure how the idea expanded, but I am imagining that Alan Stevens and a few others seeing the value of expanding the idea into a demo. Pinging Alan today, I go the idea that the “incubation” was extremely fast.

By the time Alan came down to photograph and participate in our session, the idea was already a demo in one of the session rooms, with a projected, etc.

The Players

Here is the list of players, in no particular order:

Gregory A. Beamer (me) – I am a proponent of TDD (Test Driven Development) and am actively looking at how BDD (Business Driven Development) fits into testing. I am not a purist on TDD, although I am passionate about tests.

Alan Stevens – Alan is a proponent of TDD, but even a more active proponent of community. Alan was responsible for the Open Spaces sessions at DevLink.

Corey Haines – Corey is a strong proponent of both TDD and BDD. From conversations, it is evident Corey is more of a purist than I am.

Steve Harman – Steve is a guy who, according to others, “goes from 0 to 60 in 2 seconds”. Steve is passionate about TDD and BDD and speaks on a very deep level about things he is passionate about. I would love to attend one of his 300 level sessions some day.

Jim Holmes – This was my first opportunity to meet Jim Holmes. After the “fiasco”, Jim was facilitating the post mortem discussion between Michael, Steve, myself and a few others. Jim also helped referee the session.

Michael Wood – Michael was involved in the original discussion (five or six people and a laptop) and was also involved in some of the facilitation of the post mortem.

Mike Eaton – Mike acted as the primary referee in the session and attempted to keep it under control.

The Session

I walked into the session late, so I did not see the first few minutes. The session used the example of a DevLink type of lunch where X number of people had to be fed. This example was chosen at the session rather than set up before hand.

From the post mortem, it was my understanding that there was no pre-session meeting (in the hall?) so the session just flowed.

There was also a question as to what the session’s goal was. Here are different ideas I heard about the session:

Demo to teach beginners something about TDD

Open session demoing TDD and showing the variety of thoughts people have about TDD

Session illustrating the right way to do TDD for those who do not know TDD

While these goals might seem complementary, the overarching goals for a “true” beginner’s session and a session showing the right way are different, as is the goal for an open session with a demo.

The Train Wreck

The first clue of a train wreck came when the test class was renamed for the second or third time. The first confirmation of a train wreck came when the participants were informed that “#DevLink”Twitter group was abuzz on the session. Some of the nicer comments:

Good idea, poor execution on the #devlink TDD demo. If this is aimed at "new to TDD," there’s WAY too much religion, not enough fundamentals.

Macs don’t support TDD – so I’ve learned at #devlink open spaces – also you flip the bird a lot when doing TDD

If one went down mechanics and mindsets, there was the Mac, which was really less a problem once you got on it than previously thought. There was also the religion: how pure should you worship your *DD. And, there was a lot of minutia, especially surrounding the naming of classes and methods.

The biggest “sin” of the session was we lost the core audience. Although not everyone was aware, the session was touted as a “beginner’s TDD” session. Talking to Sarah Dutkiewicz after the session, I found out she walked completely confused prior to my walking in.

Lessons Learned

The first lesson we can learn his is you have to have a goal in mind. The goal has to be communicated amongst the participants. If we would have had a “quick two minute meeting in the hall”, prior to the session, the wreck could have been avoided.

Second, you should keep the number of people in list of participants down to a reasonable number. And, while you might want various points of view in the mix, make sure that all are willing to focus on the same goal. I am not sure this would have been a problem with anyone in this group. While we do have different views on TDD, everyone in the group is a consummate professional and willing to tone down a bit for a common goal.

Third, while it is nice to make up scenarios on the fly, the tried and true examples are often the best place to start. As Steve suggested after the session, the typical “canonical” bank transaction scenario would have been a better place to start, as every person in the room would have recognized that scenario and the participants would have been familiar with it.

Fourth. Even if it is an open session, there has to be a “boss” or a “referee”. This is the person who owns the show and is responsible for keeping control of the session and getting the players back on track. The players have to walk in agreeing that the referee has the power to pull things back into place.


It would be easy, as some tweets have suggested, defining this train wreck by the personalities involved. But this would not do justice to the reality that even the most consummate professional can get off track. It is my hope that


2 Responses to The TDD Session at DevLink – Anatomy of a Train Wreck

  1. Corey Haines says:

    Good write-up. You definitely capture some of the main problems, including the lack of directed goals/referees.

  2. John says:

    Yes, it is ok to use Devlinker. I am looking for suggestions on how to improve devLink 2009, so please feel free to drop me an e-mail or hit my blog.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: