The last couple of months have been full speed and not much time to reflect and write. The fact that we’re pair programming on the team gives me less time to think about great blog subjects.
As an architect, it’s hard to find enough time to complete a meaningful unit of work without doing the dreaded “architect-commit-and-run” move. However, I found that when I have time to program, the pair programming culture on our team works really well. Even though the whole team is very excited about pair programming, there’s usually someone who’s not paired up when I get back from a meeting or finish some paperwork. Pairing up with someone is a great way to get some meaningful work completed in the middle of a day full of interruptions.
The team I’m on now is also remarkably good with pair programming, so it’s always fun. For most of the time, pair programming has been the default, but I ended up occasionally working solo for a few days in a row every now and then. Then, I was unable to pair for a few days. I found myself more easy distracted, more nervous about the quality of my work, and at the end of the day, more exhausted. Two of my team mates reported similar experience.
I think an instrumental part of the success of pair programming on this team was both to apply a little bit of force in making sure that people switched pairs daily for a while and the fact that team allowed the more skeptical members to pair programming less. In the end, everyone prefers pairing for almost all their work. After our last retrospective, we’ve instituted a pair programming star: An area on our whiteboard where the names of the team members are listed in a circle. Every time two people pair up, we draw a line between their names. Sadly, as I’m knee deep in analyzing the next release, my name doesn’t have many lines going to it.
But I hope that will change. Pair programming should be instrumental to the daily work of any architect.