Thanks to those that came to my session this morning at Agile2012. There was some great conversations and I had a lot of fun. My slides should be available in the schedule app soon.

Here is the gist of the exercise that Corey Haines had at his session yesterday that “broke my brain”. I found it to be a great set of constraints that really forced me to think about another way to solve the problem than I am use to. A must try!

I would just like to also thank all the volunteers and stage producers that made this a great experience for me.

Yesterday Jason Cheong-Kee-You and myself presented our session Deliberate Practice – becoming a better programmer at AgileTour Toronto 2011. We had a great turn out, and very active audience that made it a great experience for Jason and myself. The slides from the session are available on slideshare. There is further information on the practice that I have done at Thoughtcorp in my recent blog posts

• Practice Built In
• TDD – How to get started

We are both interested in presenting this session again at another venue. Contact me if you know of an event, alex_AT_alexaitken.com.

Thanks again to the attendees, sponsors and volunteers that made the conference happen. I hope to see everyone again next year.

Earlier this week I told you about some of our experiences with our 1 hour a week TDD sessions. I would like to share a great tool that came out of one of those sessions.

In one session, I explained the 4 contact points of software development and that you should only change one at a time.

The 4 contact points are:

• Writing test code
• Writing production code
• Refactoring test code
• Refactoring production code

Focusing on only doing one of these things at time, can keep you out of trouble and more importantly give context to the conversations with your pair programmer. When pairing the navigator can now notice that the driver is refactoring the code instead of making the test pass or refactoring both production code and test code with out running all the tests in between. For me this is the one set of rules that really helps keep you engaged when you are the navigator in the pair.

For some of the participants in the session this was new information and really got people thinking. One pair, Nick and Shan, embodied these rules in paper selector that they used to communicate which particular point they were doing at a time. You can see the “selector” token they created.

Before they would switch from writing a test to writing production code they would turn their selector to “Write Code” then begin writing the code to make the test pass. Once the test pasted they would decide if they would refactor or write another test and turn the selector to the appropriate side.

The pair always knew what type of work they where attempting to do – they could just look at the selector in front of them. They also found that it really helped them focus on doing only one type of work at a time and reminded them to look at all the options of what they could do once they finished a step.

I thought this was a great tool and worth sharing. Try making your own and see how it feels to focus on one type of work at a time.

Earlier I did a post on creating a practice space to learn Test Driven Development. We listened to my advice and did this at Thoughtcorp. Over several months we did a single 1 hour session per week.

We followed a basic format:

• Get together in a group.
• Talk for a short time (5 min) about the problem we are solving or a new concept to add to our practice.
• Pair up.
• Work on the problem for 45min.
• Come together and debrief with what we learned and observed.
• Recount of our experience

We didn’t stray from the format, however we did change around the problem we were trying to solve and the constraints we put on it.

When we started, the only explanation were the 3 laws of TDD and to challenge your pair to get the test passing in less than 30 seconds. We used Conway’s Game of Life as the problem to solve and deleted the code at the end of the session. We used this for about 4 weeks, at the end of that time the general observation is that everyone was getting tired of working on the same problem.

The week after we changed to do the Bowling Game, this caused a resurgence of energy in the group. During several weeks of working on the bowling game, we experimented with keeping code to be used the next week. Keeping the code around, did in at least one case allow for a greater understanding of refactoring. When you showed the code to the new person you were pairing with, they would point out areas of the code that didn’t expose their meaning well. Again after 4-6 of doing the bowling game, the energy level around that problem dropped.

The following week we moved to some simpler katas like Fizz Buzz, Backwards Talk and Roman Numerals. These allowed for pairs to choose what they wanted to work on and they could have complete solutions inside the 45 minutes. This definitely was rewarding outcome. It also meant that the solutions were so small and easy to visualize that more energy was put into refactoring and how small the tests could be.

Another variation we added was to do the simpler katas but follow the Object Calisthenic rules. This really drives at writing Object Oriented solutions. I plan to cover Object Calisthenics in more detail in a future post, stay tuned for that.

Observations

The Game of Life and the Bowling Game are katas that have a large solution space and many developers primarily focus on creating the solution. The act of TDD and refactoring and Object Oriented (OO) design take a back seat in these problems, at least when they are first learning the practices.

Small, katas made the act of solving the problem so simple that focusing on how you practiced TDD became the challenge. However these problems are small and don’t really benefit from really good OO design. Which means most solutions would end up as single methods with a few if statements. This allows for good TDD some refactoring, but not much practice around OO design.

Object Calisthenics forces you to refactor and look for better OO design to stay in compliance with the rules. These constraints changes simple problems in to much more challenging ones, the solutions are much less obvious and you have to listen to your tests. It makes you really work your OO design muscles.

The 10 minute debrief at the end is the most valuable part of the session, don’t skip it. This is were everyone shared what they learned or had difficulty with. Everyone has a different point of view, and those really help everyone else learn.

Conclusions

1 hour a week is a great starting point to help build up your TDD skills and introduce everyone to Deliberate Practice. Everyone that attended the sessions regularly, felt more confident in using TDD and had a lot of fun doing it.

Our team got a huge pay off, we were able to practice TDD in more areas of the code base than before and all of our automated tests became more effective and easier to write.

Writing automated tests that help you drive your development is a powerful tool that every software developer should try to acquire. The biggest problem is the learning curve, how do you go from just knowing about it to being able to do it all the time? This may seem like an enormous task, and at face value it is, but you can start the ball rolling quite easily.

Many, including myself, try to start implementing test driven development directly in their project. This is a very noble effort, but in the majority of cases it fails and leaves the team with the understanding that the cost of testing is too high and not worth doing.

There is another way.

Be Up Front

• Becoming good at writing test code is hard.
• Writing good test code is different than writing good production code.
• Writing tests will change the way you write production code.
• Writing tests for code that were not designed to be testable is the hardest kind of tests to write.

Since tests will change the production code and untestable code is the hardest to start testing, your day-to-day project is probably not the best place to get your feet wet. What you are looking for is practice space, an environment where you can extend your skills without deadlines pressuring you back to your comfortable ways of developing.

Create a Practice Space

To create the simplest practice space you only need a few things.

• A very basic understanding of the TDD steps.
• A development environment with a testing tool, Eclipse and JUnit are an easy start in the java world.
• At least 1 hour of time to dedicate.
• A peer to pair program with, you learn faster when you collaborate with a peer.
• A problem to work on.
• Iterate!

Find the amount of time to dedicate that you can continually do every week. The constant practice is what will allow this new skill to stick and eventually turn into a habit.

Having another person pair with you, means you are less likely to get stuck. If both of you get stuck all the time, the problem you are currently working may be a bit above your current skill level, select a simpler one and try again.

What kinds of problems should you use to start your journey into the world of TDD? Some good ones to start out with are what are known as coding katas. A few I would suggest are:

• Backwards Talk
• FizzBuzz
• Bowling Game
• Prime Factors
• Shunting Yard Algorithm
• and many more at codingkata.org and codingdojo.org

Practice Makes Perfect

This will give you a great starting point. After practicing for a while you will start seeing opportunities where you can easily start using tests to drive your day-to-day development. You need to practice to become good. Concert pianists don’t just start performing in front of a paying audience.