How Pair Programming Reduces Distraction

Pair programming is not for everyone. Some people love it, some people hate it. It almost seems there is nothing in the middle.

I'm more in the camp of people preferring pair programming. For many different reasons but I keep the discussion for a different post.

In this one I'd like to describe an example for what happened to me yesterday. I was working with one or my fellow software engineers, Jason, and while we were looking through a nasty C++ link problem we discovered a small item in an adjacent code area that we felt should be cleaned up. So I took a card and wrote it down as a story and returned back to the problem at hand.

Jason was surprised and made comment saying that by taking a note we would actually avoid being distracted. Although I have worked like that for years my colleague is newer to pair programming and that was probably the reason why he noticed what I did. For me it was just normal mode of operation. I did it unconsciously.

Based on my colleagues observation I think there is a lesson to be learned: First there is the specific case. When you come across something that should be done then just take a note (create a 'story' card). Don't let yourself get distracted. That way there is only a small interruption and then you are back on the problem at hand. Secondly, don't assume that the way you work is normal in the sense that everybody knows all the techniques you are using. It pays off to make yourself aware of this and sometimes it takes a good observer like Jason making a comment to become aware of what you are actually doing. So keep your ears open!

Dealing With Uncertainty in Stories

Extreme Programming uses stories to define the scope of a system. Sometimes teams have difficulties to estimate the size of stories with a satisfying accuracy. Different approaches to address this issue are possible, e.g. making stories even smaller.

Another approach is to look for the elements in a story that represent the risk. Then these elements can be addressed in a time-boxed spike (or experiment). The remainder stays thus becomes a low risk story.

Risky elements may be new technologies that need to be tried first, or a cool new user interface widget. An example of the later could mean that you might want to implement a simple (maybe even un-cool) version of the interface first. And separately you play the story with the spike for the cool widget. That way you deliver value while at the same time pushing the envelope in a time-boxed fashion. If the outcome of the spike is good then you can play a third story to improve the user interface.

With this approach I have seen different teams addressing risk, and at the same time improve their estimation skills. There are certainly more techniques. If you know of another simple way to deal with this I would be interested to hear from you.