The Boston Software Craftsmanship Meetup group met recently to play a couple of programming games. They were gracious enough to let me sit in as one of their own. The games were to demonstrate the value of pair programming and test-driven development (TDD). I already liked the idea of these techniques and after seeing them up close, I’m a big fan.
We started the night with a game of Pair Programming Musical Chairs. We split into pairs and got started on a simple problem using TDD. Then, at regular intervals a timer would go off and we would switch partners. One partner would stay with the code and the other partner would start in with a new partner on new code. Each time we switched partners, we had to team up with a partner we hadn’t worked with yet. Plus, if we stayed with our code last time, we had to move to new code this time and vice versa.
One of the advantages of TDD, from the developers’ standpoint, is that it breaks complex problems into very small steps that are relatively easy to achieve. This naturally builds confidence and encourages developers to push on quickly.
I was impressed by how many different ways there are to do the same thing. Whether because of developer preferences or differences in languages and frameworks, code that does the same thing can look very different. It was interesting to see how different a program looks when the same basic functionality is written in C# vs Ruby vs Java. It was also interesting to see how different that same functionality could look when written in the same language but by two different teams.
This in turn impressed upon me the importance of good documentation and comments in the code. Switching partners every so many minutes simulates the regular turnover of developers in enterprise organizations, but at a really accelerated rate. There were times when I couldn’t follow the code and had no idea who had written it, because he or she had moved on at least twice since writing it. I’m sure if there are any professional developers reading this, it sounds familiar.
Also, the very real value of keeping down technical debt became readily apparent. The more simple and straightforward the code was, the easier it was to add new functionality to it. When the functionality was added piecemeal, without refactoring to simplify out the unnecessary bits, it was very difficult to understand and modify, even though the actual functionality in our case was trivial. On the other hand, when the code was rewritten to simplify out the complications it was relatively trivial to add new functionality. And sometimes we’d luck out and a side effect of the simpler code would be that future test cases were already solved.
By and by, I’d say Pair Programming Musical Chairs is a good team-building exercise for Agile teams. In a workplace environment, a series of actual work problems could be used. This would probably require the development teams to start with writing tests for the problem before starting into coding. The whole process could take several hours. But provide drinks and snacks and encourage the developers to have fun. In the end, they’ll understand each other better, they might learn a new trick or two, and they might even crank out some production-ready code.