Pairing, Welcome Distractions and the Mighty Pau

Pairing, Welcome Distractions and the Mighty Pau

One of the many aspects of eXtreme Programming practices we have adopted is Pair Programming. I wanted to tell you how we find it works here and in doing so give you an insight into the culture and what it’s like working here.

We currently do pair programming for all production software developed here. I’m personally a massive advocate of this due to these massive advantages:

• Development expertise and knowledge are both shared more effectively. This is particularly good for brining junior resources up to speed
  
• The context of the problems we face are also shared more, and so our solutions are generally improved
  
• Code quality is better
  
• There are less bugs
  
• It’s fun. Developers often enjoy ‘ping pong’ style development which I delve into more in a future post
  
• How well the practice integrates with other aspects of extreme programming. (I have another blog on this aspect here)
  

The above is the most important aspect worth discussing in my opinion. The main side effect noticed previously of adopting pair programming is the really high concentration levels for long spells of time. I personally think this is an area we need to improve currently, but (especially when I first started here) we would sit down after 9am standup/coffee and start pairing almost non-stop until lunchtime. With another person there keeping you focused and (ideally) no one ever drifting off to read the BBC website it is really intense. We therefore always highlight this to potential recruits as it is sometimes quite mentally draining for people with a different mindset.

Due to this we have always had ‘distractions’. These have manifested themselves in many manners over recent years. Remote control cars, air/smoke breaks, a wallboard that allows for youtube videos to be posted to it.

In much the same way that well known tech companies have remote control boats, games rooms, slides or Xboxes we promote this (when appropriate) with one massive but obvious caveat. If the intensity isn’t there, the distractions aren’t appropriate. If we aren’t working hard enough that these aspects are deemed effective release in order to continue working with a creative mindset then the distractions soon disappear. This isn’t even something that historically has needed any management, if the distractions become too much (like the wallboard talking to much) you can bet that someone will go and turn it off.

Two historical but noteworthy distractions are the ‘Wally Pages’ and Pau Facts. the sharing of ‘photoshopping’ or Chuck Norris style jokes about two of our favourite developers.

I have recently been starting to change my thoughts on this topic slightly. Having read other blogs on the subject and having had some realisations myself, I worry that getting people ‘out of the zone’ en mass can be a little overly distracting. Maybe this is the reason that other companies ‘distractions’ involve someone getting up and being out of the working environment. The short break is still there, but without the costly/sometime frustrating interruptions for those intensely focused. We have recently moved into a new office. The distractions we had previously have therefore gone. Its essentially a clean slate on this matter and therefore something I am keen to see how it evolves

We have also recently started to discuss some of the issues with pair programming too. People not seeing stories through to completion (causing slightly diminished responsibility) being the main one but I feel this is largely when it’s being done badly (again in my opinion not that of all at WDS). I was going to completely rewrite my blog, but thought I’ll just do an update in some time when we can discuss any changes we made and why

The intention was to give you an overview of our environment and views on pair programming. We’d be interested in how others have found the practice

I hope this helps. Feel free to comment, share and discuss

Chris Watkins