The agile software development practice I like the most, and at the same time, the one I find the most difficult is pair programming. Each individual has his/her own way of working, and characteristics such as motivation, engagement, habits, open-mindedness, and coding/design style varies a lot from individuals. Sometimes, to get a balance between these differences is quite hard. I am still not an expert in pair programming coaching, but I've been learning a lot on my current assignment.
And from this experience, it seems that clients are definitely more involved and amused when it comes pairing following the ping pong pattern.
Ping Pong Pattern
It happens when the developer 1 from a pair implements a test for a given feature and see it failing, then passes the keyboard to developer 2 who makes the test pass, do some refactoring on the code and implements another test, passing the keyboard back to developer 1 to do the same thing and continue until the feature is done.
Why Do We Like
- Challenge - Each time a developer writes a test for you to make it pass, it sounds like a challenge, then you do it and write another one, challenging him back.
- Dynamics - The worse thing is a developer that just hogs the keyboard, making you feel a useless. Ping pong pairing makes you swap keyboard more frequently.
- Engagement - Developers are much more engaged because they are constantly coding, not only observing.
- Fun - It is so much fun when you have all the above items together!
Last Wednesday, 5th of November, we run our first Coding Dojo session at Sydney office. We had a reasonable number of attendants, and the experience was fantastic, although we still have some points to improve.
The idea was originally from my friend and flat-mate Mark Needham. Since we moved in to our new place, he came up with the idea of getting together every week to solve some CodeKatas at home, exploring a different language. We decided it would be more interesting if we could broaden the idea, and decided to organise a session at the Community College in the ThoughtWorks office.
How did we run:
There were six people attending, so we decided to split it into three pairs, each with their own solution, rotating every ten minutes.
We had three design discussion breaks, one in the beginning, one in the middle and another at the end of the session. Since the focus was on object-oriented design, we chose to implement the bowling game, extracted from Uncle Bob Martin's book. We did it following the Object Calisthenics rules, which are:
- Use only one level of indentation per method
- Don't use the else keyword
- Wrap all primitives and strings (strong types)
- Use only one dot per line
- Don't abbreviate
- Keep all entities small
- Don't use any classes with more than two instance variables
- Use first-class collections
- Don't use any getters/setters/properties
What was cool:
Apart from being an amusing experience, it was quite interesting to see the different approaches that people take to solve the same problem, - the design, the way they write tests, the code style, pretty cool. The pair swapping was also another nice experience. It was gratifying to pair with ThoughtWorkers other than the ones on my current project, like David Cameron and Nick Carroll.
For the next session, I would like to experiment with another approach.
Restrict the number participants from seven to ten developers. And instead of splitting them into as many pairs as possible, having all seated around a table, where there would be only one pair working on the solution, while the others are watching through a projector. They are free to help whenever they want, providing suggestions, ideas for design, algorithm, etc. The developers pairing would be swapped every ten minutes, by other ones participating. Although the number of developers participating is restricted, anyone is welcome to attend as a watcher.
I reckon we would be much more productive this way, when everyone is working on the same thing, centralizing the focus, and learning even more from other developers.