TDD Dojo

I’ve been conducting lunch classes at work to help us improve the confidence in our software. I call these sessions “Q.E.D.”, based on my foundation in mathematics and my practice of applying mathematical proof to software (see my other blog qedcode.com).

In the past, these have been lectures, where I present mathematical concepts like Degrees of freedom, Closure, or how to write Provable APIs. These sessions have earned me the nickname “Professor”, which I answer to proudly. But lately, I’ve been thinking it would be better for the team if I were a “Sensei” instead.

The end of lectures

Yoda As the Professor, I would get up in front of the class and give a lecture. This would include not just PowerPoint, but also a good deal of coding in Visual Studio. I would get some good questions from the group, and I would also throw out questions of my own.

Then I would assign homework. Make this unit test pass, or refactor that API to make it more provable. People would do the homework individually and email me the results. At the beginning of the next class, I would choose the person who did the best homework and recognize them with the Yoda Award. They get to keep Yoda at their desk until next week’s class.

The main problem I saw with this kind of session was that not many people were putting the concepts into practice. Only two or three people would email me homework each week. It was a different set of people each time, so I wasn’t concerned about particular individuals. But work and other obligations got in the way, people didn’t seek help from me or each other, and the week just slipped by.

To solve this problem, I decided that we should do homework in class. When thinking about how practically to do that, I remembered the evenings I spent at a local meetup group called Geek Night, hosted at Thought Works and led by local Though Worker Paul Hammant. At Geek Night, we pair program on open source projects.

To get people practicing together, we need the pair programming bit more than the open source bit. So I decided to have them pair on very simple exercises at first. We are starting off with the Bowling Game Kata. But instead of solving the whole thing, I’ve broken it down. The original kata has you write test like “When I roll 20 gutters, my score is zero” and “When I roll 12 strikes, my score is 300.” That’s too big, in my opinion. The problem should be broken down into testable pieces that you can then assemble into a working solution.

The first piece that we are working on is a class called GameData. This class will record all of the rolls. It will eventually be used by the Frame class, which will observe rolls by index. This leads to a number of simpler test, like “there are initially no rolls” and “after one roll, you can retrieve the first roll by index.”

With that inspiration, I closed the classroom and opened a dojo. In a martial arts dojo, the sensei doesn’t stand at the front. He walks around and interacts with the students. The students work individually or in pairs on routine forms. The sensei will call out commands, and correct individual students on their form.

The rules of the dojo

I brought in a deck of cards. I leave two cards of the same value on each desk (for example the 3 of hearts and the 3 of spades). The other two (3 of clubs and 3 of diamonds), I put in a deck near the door. When you enter the room, you take a card. You sit at the table with that value. This creates up to 13 pairs. I have on average 12 people attend, so I only used Ace through 6. If we have extra people, then we create additional pairs. If we have empty chairs, we consolidate. And if we have an odd number of people, one pair becomes a triple.

Each person brings a laptop with Visual Studio 2010. They have all pulled the same solution from TFS and mapped it to their drive. When we are in the dojo, we cannot connect to the network. So we all open the solution and select “Go Offline”.

I give the group a requirement to test. For example, “Given a GameData class, the Rolls collection should initially be empty.” One person writes that test, which should initially not compile (the test uses a property that the code doesn’t have yet). The other makes it compile (by adding the GameData.Rolls property), sees it fail, and then makes it pass.

I walk around the room observing how each pair is doing. If they write working code without seeing the test fail, I ask them to delete the code and see the failure. If they are leaving sloppy tests behind, I ask them to refactor. If they are using the debugger, I ask them to make the test fail in such a way as to tell you why it failed. And if their test names don’t reveal their intention, I ask them to rename them.

When every pair has the test working, I call out the next test. “When I add a roll, I can get that roll by index 0.” The person who wrote the code last time writes the test this time. Then they pass it off to their partner to write the code.

In the first hour, we were able to get through 4 tests. This included learning the rules of the dojo, setting up the project (for those who didn’t come prepared), and leaving 10 minutes at the end.

During the last 10 minutes, I ask each pair to bring their laptop to the projector and show us their tests. We all ask questions about the tests and the code. The pair defends their naming, their refactoring, and their implementation. “The test”, I explain, “is the example that you give to the consumers of your API. It says, ‘I want you to use this class in this way.’ Is this the way you want people to see your API?”

Finally, each pair selects one other pair that has the best code. They cannot select themselves. The pair must vote as one. They write down that pair’s number (Ace through 6 in my case). Then we reveal the votes and decide the winner. The winners get to share Yoda for the week.

When they get back to their desks, they hit the “Go Online” button to reconnect the solution to TFS. The winning pair gets to check in their code. Everyone else must roll back. Then next week, everyone gets latest and starts from there. This encourages people to vote for the code that they want to work on.

The reaction so far

People really seemed to enjoy the first session. More importantly, it was the most engaged that I saw them since we started these lunches.

All of the pairs made some pretty basic mistakes. Not all of them realized that they were mistakes. For example, one pair did not refactor between tests. They took each test as a separate requirement that, once completed, could not be altered. So when they saw that another pair had refactored the first test, they complained that they had rewritten requirements. I explained that the requirement was still met, but now the design was improved.

If I were a real sensei, I would not feel the need to explain. I would simply correct, expecting that understanding will come in time. I don’t feel that I can take this approach with my team at this point. Perhaps eventually we will be able to leave our egos at the dojo door.

I had to come up with the rule that you vote for another pair because initially everyone voted for themselves. Rolling back your own code is painful at first. Over time, they will recognize that deleting your project at the end of the kata is actually quite a cleansing sensation.

Leave a Reply

You must be logged in to post a comment.