Mark Needham

Thoughts on Software Development

Archive for the ‘Pair Programming’ Category

Pair Programming: So you don’t want to do it…

with 8 comments

I’ve worked on several software development teams over the last few years – some that pair programmed all the time and some that didn’t – and one of the key things that I’ve noticed is that the level of collaboration on these teams was significantly higher when pair programming was being done on a regular basis.

The following are some of the observations I have noticed in teams which don’t pair program frequently.

A culture of silence

The amount of communication in a team which doesn’t pair is almost by that very definition going to be lower than in one that does – you don’t have that almost constant dialogue/discussion going on that you get when a pair are at the keyboard since everyone is head down coding in their own little world.

A consequence of this is that other types of communication are also reduced.

When a room is full of people pairing it’s not uncommon for someone to shout across the room for a colleague to come and help them and their pair with something. Since there is already a lot of communication going on this doesn’t feel that unusual and since other people in the room might hear us speaking we can also get the benefits of osmotic communication.

When we don’t have that it feels very awkward to do this and in fact often the person you call won’t actually hear you since their head is down and focused on the task their working on.

The inclination the next time you need help is to just work it out yourself, further harming team collaboration.

Code silos

Another consequence of having people working alone is that people become very specialised in certain areas of the code base and then when they either leave the project or are ill there isn’t anyone else who knows their area to work in that area of the code.

It becomes obvious that we have silos in the code base when code starts to be referred to as “X’s code’ or ‘X’s way of doing things”. Another danger sign is when there is a lot of talk about “handovers” – a sure sign that collaboration hasn’t been taking place.

One way to address this problem without pair programming is to mandate that code reviews must be done before code written alone is checked into the source control system.

The problem with this is that there isn’t really way to enforce it if people don’t want to have their code looked at by someone else beyond reverting their changes which seems perhaps over confrontational.

Repeated code

The tendency to end up with several people solving the same problem is one that rears itself quite frequently when people are working alone.

Since each developer doesn’t have as much visibility into what their colleagues have been working on – the sharing of knowledge that pair programming encourages is absent – we often end up with several sub par solutions to the same problem instead of collaborating to come up with one good solution.

Repeated code is perhaps the biggest waste of any developer’s time – we are adding no value at all by doing it and are creating confusion for our colleagues as they now don’t know which bit of code is the correct one to use.

In Summary

I’m sure there are ways to overcome these problems but I’ve never seen it done effectively without having people working together more closely.

I’d be interested in hearing ways that others have created collaborative teams without having developers collaborating closely by using a practice such as pair programming.

Written by Mark Needham

June 8th, 2009 at 5:05 pm

Posted in Pair Programming

Tagged with

Pair Programming: Refactoring

with 5 comments

One area of development where I have sometimes wondered about the value that we can get from pair programming is when we’re spending time doing some major refactoring of our code base.

The reason I felt that pairing on big refactoring tasks might be difficult compared to when working on a story together is that with a story there tends to be a more defined goal and the business have defined that goal whereas with a refactoring task that goal is often less clear and people have much wider ranging differing opinions about the approach that should be taken.

Having spent time pairing on some refactoring work for most of the last week I have changed my mind and I think that pairing on refactoring tasks is actually extremely valuable – certainly equally as valuable as pairing on story work and perhaps more so.

What I noticed in my time pairing on this task is that actually although there is more conflict over the approach that should be taken this actually works out reasonably well in terms of driving an approach that is somewhere between pragmatic and dogmatic.

From my experience, the mentality when you’re the driver in a refactoring session is pretty much to want to fix everything that you come across but having someone else alongside you helps to rein in this desire and focus on making the fixes that add value to the code right now.

I was quite surprised to notice that within just one keyboard switch we had both suggested to the other that making a particular refactoring should probably be added to our ‘refactoring list’ to have a look at later on rather than looking at it now and potentially getting into a yak shaving situation.

Another thing I noticed was that the navigator was often able to point out things that the other person didn’t see – sometimes making a certain change to the code had a bigger impact than the driver had expected and the navigator was able to spot this quickly and initiate a discussion about what the next step should be before we had gone too far down the wrong path.

Refactoring code effectively and not making mistakes when doing so is one of the more difficult skills to learn as a developer and I think it is very difficult to learn by just working on your own since the approach to effectively refactor code by taking very small steps is not necessarily obvious.

While there are certainly books which explain how to do refactorings on our code a lot of the approaches that I like to use have been taught to me by more experienced people that I’ve had the chance to pair with. Pairing creates the opportunity for these skills to be passed on to other members of the team.

Written by Mark Needham

May 26th, 2009 at 11:44 pm

Pair Programming: It’s not about equal keyboard time

with 6 comments

My colleague Nick Carroll recently blogged some ideas about what to do if your pair is hogging the keyboard, suggesting using a timer which keeps track of how long each person has had at the keyboard as a useful way of ensuring that both people in the pair stay more engaged.

While I can see the thinking behind this I think it is addressing the wrong problem.

From my experience we don’t always want to be moving the keyboard between the two people quickly at all times – I have certainly seen times where it makes sense for one person to be spending more time at the keyboard than the other.

A particular example of this is when there is a difference in experience between the two people at the particular skills required to complete the task they’re working on.

On a project I worked on around 18 months ago I was struggling to stay engaged as the navigator as I didn’t really understand what was going on and the half/half split in keyboard time wasn’t really helping.

Chatting with a more experienced colleague about this at the time he suggested that when I paired with him he was perfectly happy to spend the majority of the time navigating while I drove so that I could get more understanding around the code base and become more useful to the team.

This colleague was clearly keeping the big picture in mind and I haven’t come across a situation since then where someone acted so selflessly for the benefit of the team.

The lesson for me from this situation is that sometimes it makes sense for the person who can gain most from driving to do so more frequently.

The other thing I think Nick’s post is suggesting is that the only way for you to be engaged in a pair is when you are at the keyboard, which I don’t believe to be correct.

The role of the navigator shouldn’t be underestimated as when it’s done well it provides a very good complement to the person driving as that person is taking a bigger picture view of what the pair are working on and ensuring that the code being written is still fitting in with the rest of the system. Dahlia has written an informative post about some of the things that she does when navigating in a pair.

Another idea Dan suggested to me is to commentate on what you think is happening/what the other person is doing at the keyboard when you’re navigating and feeling a bit lost.

I’ve spent quite a bit of time working with Lu Ning on some Javascript on our project recently and have been trying out this approach there and I think it’s helped me to understand things better although clearly it takes a lot of patience from the driver if you take this approach.

Written by Mark Needham

May 23rd, 2009 at 4:35 pm

Posted in Pair Programming

Tagged with

Pair Programming: When your pair steps away

without comments

I’ve been having a bit of a discussion recently with some of my colleagues about what we should do when pair programming and one of the people in the pair has to step away to go and help someone else or to take part in an estimation session or whatever it happens to be.

If we’re pairing in an effective way then it should be possible for the person still at the computer to keep on going on the story/task that the pair were working on alone. Obviously sometimes that isn’t the case especially if one person has been driving for the majority of the time but for this post we’ll assume that both people are capable of continuing alone.

Continuing alone doesn’t necessarily mean that you become the code fairy, which is where one of the people in a pair goes and implements the functionality of something they had been pairing on in their own favoured style.

My initial thought is that if the absence is only short term then you shouldn’t plow on too much otherwise you need to spend time bringing them back on the same page when they return.

To give an example, a couple of weeks ago I was pairing with a colleague and we were retrieving a value from a Dictionary if it existed and creating a value in the Dictionary if it did not exist.

Dave had recently shown me quite a clean way of doing this which I wanted to discuss with my colleague in case they hadn’t seen it before – the approach we had been taking to solve this problem wasn’t along these lines before my pair was called away.

public class DictionaryExample
    private readonly Dictionary<string, string> values = new Dictionary<string, string>();
    public string FindValue(string key)
            values[key] = "somethingNew";
        return values[key];

When he came back I suggested this approach and he was happy to go with it.

I sometimes write down stuff I’m unsure of when pairing and I find that if my pair goes off for a short amount of time then this can be a useful time to look that up.

If we decide to keep on going during their absence then I think it’s important that we keep going down the same path that we were when we were pairing to reduce the amount of catching up our pair needs to do when they return.

If they have gone away for a longer period of time then we should treat it as them having left the pair and we can look for someone else to pair with or just code as if we were working alone.

That’s my current thinking on this – some colleagues have suggested they think it’s better if we just keep on coding regardless but I think this approach finds a happy medium.

Written by Mark Needham

May 3rd, 2009 at 7:08 pm

Posted in Pair Programming

Tagged with

Pair Programming: The Code Fairy

with 6 comments

One of the hardest situations that comes up when pair programming is when you want to solve a problem in a certain way but you can’t persuade your pair that it’s the approach you should take.

The temptation in these situations is to wait until your pair isn’t around, maybe by staying late at the end of the day or coming in early the next day and then making the changes to the code that you wanted to make but didn’t when you were pairing with them.

My colleague Cam Swords has coined this pattern of behaviour ‘the code fairy‘ and it’s something that we want to try and avoid in software development teams.

The thing to note here is that you’re following another direction than you had been when pairing, not that you’re working alone on the code just because you’re pair can’t work with you at the moment for example.

The problem with following this approach is that you lose the benefit of pairing in that you have two eyes looking at the code and reducing the likelihood of stupid code being put into the code base – by stupid I mean code which has been written with cleverness in mind rather than simplicity. I find that when I work alone those types of ideas are much more likely to seem a good idea than when I have someone else there to put me right.

When we can’t convince our pair to follow our approach it is often due to the fact that we can’t articulate why we prefer it well enough to convince them. In a recent conversation with Cam about the problem of persuading people of our approach he pointed out that even if we are really good at constructing an argument for why our approach is better our pair may still not want to do it and we can’t do a lot about it.

Most recently I’ve been really enthused by the idea of writing functional OO code but I find it very frustrating that I can’t currently clearly explain why I prefer this approach to writing code over an approach which favours there being more mutable state.

I really want to go and change the code to follow that approach but it would be inconsistent with the rest of the code base as well as being less clear to my team mates since it would have been me who wrote it alone rather than doing it in collaboration with a colleague.

Another problem is that since we ended up going and re-writing the code ourselves the same situation will happen again in the future so we haven’t really achieved anything apart from temporarily making the code a bit better in our eyes. In addition there are now less people on the team who understand that particular bit of code which is not a good position to be in when we’re working in a team.

It’s definitely not easy to resist the urge to go and ‘fix’ the code on our own but for the benefit of our team mates it’s something we need to consider.

Written by Mark Needham

April 10th, 2009 at 7:28 pm

Posted in Pair Programming

Tagged with

Pair Programming: Slowly but surely

with 5 comments

I recently watched a video recorded by Uncle Bob at the Chicago Alt.NET meeting where amongst other things he talked about the importance of going slowly but surely when we’re developing code i.e. spending the time to get it right first time instead of rushing through and having to go back and fix our mistakes.

While pairing with a colleague recently it became clear to me that pair programming, when done well, drives you towards a state where you are being much more careful about the work being produced.

Two particular parts of our pairing session made this stand out for me.

  1. We were trying to work out the best way to get some data from the UI into our application. I had an idea of the best way to do this but my pair pointed out an alternative which I originally thought would might our tasks more difficult.

    After talking through the different approaches and trying out the alternative approach in code it actually turned out that my colleagues’ approach led to a much simpler solution and we were able to get that part of our task done much more quickly than I had anticipated.

  2. A bit later we were writing some tests for getting this data into our application using an ASP.NET MVC binder. Not not knowing exactly how to do this I decided to go for the obvious implementation and then triangulate this with the second test.

    It was a bit painful putting this hardcoding in to make the test pass and I was starting to wonder whether just going ahead and implementing the binding properly would have been preferable.

    As we got to the fifth field we needed to bind we realised that we had no way of getting an additional piece of data that we needed. Luckily we hadn’t gone too far down the route we were heading so it was quite easy to go and make the changes to the UI to ensure we could get the extra bit of data that we needed.

    As a result of us having to stop and actually look back at what we’d just coded it became clear that we could simplify our approach further, so we did!

    The resulting code was much different and eventually cleaner than the original solution we were driving to.

Taking our time over our code is something which is invaluable – nearly every time I take a short cut or try to do something without thinking about it properly it ends up taking longer than it would if done properly – the somewhat ironic outcome that Uncle Bob points out in the video.

When we are pairing if we want to take one of these shortcuts we need to convince our pair as well as ourself and from my experience we tend to realise that what we’re suggesting doesn’t make sense and end up coding a better solution.

That’s not to say that we sometimes don’t have to take the pragmatic approach and not do a bit of refactoring until later so we can get features completed. After all that is what we are being paid to do.

Software development for me is a lot more about thinking through our options than coding the first thing that comes to mind and pair programming helps drive this approach to problem solving.

Written by Mark Needham

March 31st, 2009 at 11:15 pm

Posted in Pair Programming

Tagged with

Pair Programming: From a Lean angle

with 2 comments

I recently watched a presentation about lean thinking and I started seeing parallels in a lot of what they were saying with the benefits that I believe we see in projects when the team pair programs.

Big Picture vs Local Optimisations

One of the biggest arguments used against pair programming is that we get half as much work done because we have two people working on one computer.

Even if we ignore the immediate flaws in that argument I think this is a case of looking at individual productivity when in fact what we really care about is the team’s productivity i.e. looking at the local optimisations instead of the big picture.

I’ve worked on teams which pair programmed the whole time and teams where pair programming was less prevalent and the difference in how well the knowledge of the code base was spread throughout the team is massively different.

When you have developers working alone knowledge sharing is much lower – people tend to become quite specialised in one area of the code meaning that the next time there’s work around that area they do it and so it spirals on and on until you’re completely reliant on them. If that person is then ill for a day we have a big problem doing any work in that area.

In terms of waste

There were 8 different types of waste described in the presentation:

  • Extra features (Over Production)
  • Delays (Wait and Queue)
  • Hand-Offs (Internal Transport)
  • Re-learning (Over Processing)
  • Partially done work (Inventory)
  • Task switching (Motion)
  • Defects
  • Unused Employee Creativity

When people are working alone they may try to pass on their knowledge to others in the team but it’s never as effective as if the other person has worked on the problem with them at the same time – there is always some information lost in a hand over – the waste of internal transport.

In the event that a person with a lot of knowledge in a certain area of the code base is ill then someone else will end up having to pick up where they left off and learn how the code works from scratch – the waste of over processing. This applies beyond just the simple situation where someone is ill – when pair programming is not being practiced people have less idea about the problems their colleagues have already solved since the benefits we would normally achieve by rotating pairs are not achieved.

Research suggests that pair programming can lead to a reduction in defects in the code produced due to the fact that we always have two people looking at the code. I think this is only true if both people in the pair are engaged – if one person isn’t then I can’t see how the defect count would change compared to having people work alone.

One of the other benefits I have found with pair programming is that it really makes you think about the value that you are adding by writing a certain piece of code. I think we are much less likely to gold plate with two people at the computer rather than just one. We therefore don’t end up with unnecessary extra features which don’t really add that much value to the customer.

When it comes to task switching I think this will always happen to an extent within a project team – people are often called away from the story work they are doing to help out with something else. When they are pairing this isn’t as disruptive since their pair can continue working on the problem until they return. If people work alone then the story work will end up on hold until they return and take the time to regain the context to continue.

It’s arguable but I’ve noticed that due to the extra discussions that happen when people are pair programming there tends to be more focus on ways to improve the way that things are being done, be it the way the code is being written, the way the tests are designed or the processes being followed. I feel pair programming encourages employee creativity which can only be a good thing as far as I’m concerned.

I can’t think of any obvious ways that pair programming would reduce the other two types of waste but I find it interesting that the majority of them are covered.

In Summary

This was just a brief look at what I consider to be one of the most effective team learning tools available to us from the angle of a methodology which recognises that learning quickly is important for successful delivery of software projects.

Every time I see pair programming not being done I become more convinced of its value.

Written by Mark Needham

March 29th, 2009 at 4:54 pm

Posted in Pair Programming

Tagged with

Pair Programming: What works for me

with 4 comments

My colleague Chris Johnston recently posted about his experiences with pair programming, eventually ending up asking for other people’s experiences in doing so.

Several of my colleagues have replied citing some of their best practices and I have previously posted about what I think makes pair programming more effective so for this post I thought I’d try and also identify the approaches that make pair programming work for me.

Keep it productive

This is the area which has been written about the most, perhaps because it’s the most visible to others.

Knowing your IDE and its’ shortcuts, taking lots of small steps, using TDD, ensuring that both people get keyboard time, keeping a list of tiny tasks, and so on are all ways that we can work more effectively as a pair.

In addition, it’s also important not to spend your time arguing because your pair doesn’t do exactly what you want them to do. Cam Swords nails this in his comment on Dahlia’s blog

– let your pair do what they want
the most senior consultants/developers dont always get what they want. If you go into pairing expecting this, you wont enjoy the experience.

This is valid even if the issue is something that you think is really important. For example if you love tests, but your pair doesnt want to write them. Why not try not writing tests? They will soon want to write tests when everything starts breaking and they will respect you more for allowing them to learn the mistake themselves.

One idea I learnt from reading Steve Pavlina’s blog, also touched on here, was that whatever we want to happen, we should do more of ourself and it will naturally happen. Therefore if we feel our pair is not listening to our ideas we should spend even more time ensuring that we are actually listening to them – I don’t always follow this advice myself but when I do it does seem to work.

Stepping one level up, it’s also useful to ensure we rotate pairs frequently to ensure that a pair doesn’t become stale or get sick of the sight of each other! I don’t have the data to back this up but I think at most we should be looking to rotate at least every few days if not more frequently.

Keep it fun

I know the majority of the time we are pair programming in a work situation and although maybe we take a slight short term productivity hit by having this element of fun, I think working in this type of environment is more conducive to success in the longer run.

If I enjoy the work I do I’m likely to be more passionate about it, learn more about it and therefore become better at doing it.

Some examples of ways to create a fun atmosphere when pairing could mean joking about stupid variable names that you have come up with or having a side conversation that you pick up when there is a lull in proceedings – when the build is running for example.

Having a fairly laid back approach and not taking the whole thing too seriously is a useful approach to take. Being able to joke about the bad code that you’ve written and then working out ways to improve it with your pair can be a fun learning experience when done in a laid back way with a pair that you trust.

Clearly there is a bit of a balance to strike here so that we do actually do some work – although it is sometimes fun to include other pairs in our banter, doing so all the time doesn’t work so well from my experience and ruins their train of thought.

Keep learning

Although a lot of the value in pairing comes from the fact that we are spreading knowledge around the team and having two eyes looking at a problem tends to result in better quality solution achieved more quickly, I think teaching our pair new things is also very important.

One of my favourite phrases that I have heard with regards to judging the success of a Project Manager is to look at each of the members of their team and see if they are better for having done the project than they were before. If they are then the Project Manager has succeeded from a people point of view.

Maybe we can apply the same logic when pairing – in every pair programming session always look to teach your pair something that they don’t know. It doesn’t even have to be something completely related to the story being worked on although it’s even more effective if that’s the case.

It could be as simple as pointing out some books or blogs you have read recently around an area of technology which you know is of interest to the other person. Sharing domain knowledge in areas which are maybe not immediately applicable is another way that we can help share knowledge with our pairs.

Never Settle

I’m sure there are other subtle gains we get out of pairing that I haven’t thought of, but I think it’s important that we constantly look for ways to improve the way we pair.

For example, I recently came across the idea of screen pairing from Brian Marick’s blog – an idea that he learnt when pairing with Corey Haines on Corey’s pair programming tour across the US.

The idea is that both pairs sit at a machine opposite each other but both see the same screen by using iChat. The thinking behind this approach is that you can more easily see your pair’s body language and that it is generally more comfortable than having both people sitting side by side. Certainly an idea to try out in a Coding Dojo type situation.

I’m sure we haven’t yet learnt all the tricks of mastering this skill so keeping an open mind is probably the most approach at this stage.


I still have a lot to learn about pair programming and these are just some of my observations so far. Coming from someone who is very much pro pair programming, we want to try and reach the stage where we can prove that there is more value to the business from having our developers pair than by having them working individually.

We can only do this by continually evaluating what we are doing and looking for ways to improve it.

Written by Mark Needham

December 17th, 2008 at 10:09 pm

Posted in Pair Programming

Tagged with

Pair Programming: The Over Eager Driver

with one comment

One of the interesting situations that can arise when pair programming is that one person dominates the driving and their pair can hardly get a look in.

This is not necessarily because they are hogging the keyboard – it is often just the case that they are the stronger technically in the pair and the other person isn’t willing to ask for the keyboard.

A big part of the value in pair programming comes from having both people taking turns at driving and navigating from my experience and there are several ideas that I have come across for trying to encourage a more collaborative approach to pair programming.

Ping Pong Pairing

The idea of this approach is to encourage the switching of the keyboard between both people very explicitly.

Based on the assumption that we are adopting a TDD approach, the first person starts out by writing the test, then they switch and the second person writes the code to make the test pass. Then they write the next test and the first person writes the code to make that test pass.

With this approach both people end up with fairly equal keyboard time and will hopefully feel more involved in the development effort.

My colleague Sam Newman previously wrote about ping pong pairing, including an approach to ensure that both members get exactly the same amount of keyboard time per day.

Learning the Art of Navigating

As a general rule I think the majority of people find it much easier to drive than to navigate.

When navigating it often feels that you are not adding value and it sometimes becomes confusing as to exactly what you should be doing.

Having said that I have worked with some phenomenally good navigators during my time pair programming. While I don’t claim to know how to teach someone how to be a good navigator (I’m still working on it myself), there do seem to be some distinct skills that you can apply to carry out this role effectively.

  • Keeping an eye on the big picture – are we solving the right problem, has this piece of code become too difficult to test, are we testing it in the correct way etc.
  • Tracking the tasks needed to complete a story and being ready to continue with the next one when the driver has finished the current one.
  • Sharing tips on how to navigate around the workspace more effectively – keyboard shortcuts, different tools etc.

If we can become equally effective at contributing as both a navigator and a driver then it doesn’t become so imperative to drive all the time.

Two of everything

This was an approach I was introduced to more recently and involves having two keyboards and two mice connected to the workstation.

The benefit of this approach is that the difficulty of prising the keyboard away is removed and we can just grab our own keyboard and start typing when we have some input to make.

Clearly this needs to be done relatively sensibly otherwise otherwise we end up with both people typing or moving the mouse at the same time. From my experience of this technique that actually rarely happens.

There is also an increased spending on equipment but I wouldn’t imagine this would be that significant.

Written by Mark Needham

November 5th, 2008 at 11:48 pm

Pair Programming: Benefits of the pair switch mid story

with 3 comments

On my current project we’ve been having some discussions around the frequency with which we rotate pairs, the feeling being that we probably keep the same pairs for a bit too long.

We discussed using techniques such as promiscuous pairing, which takes the idea of pair rotation to an extreme, but have settled on making our rotations more or less daily.

One interesting thing I noticed from some recent pair switching was the immediate benefit we can realise from the pair rotation.

When we switch pairs mid story the story champion (person who owns the story from start to end) has to get their new pair up to speed as quickly as possible.

My colleague Liz Douglass has a very precise yet effective way of doing this. From observation:

  • Describe the story or task from a high level detailing what it is we are trying to do and how it fits into the system as a whole
  • Describe what has been done so far, why that approach was taken and what is left to do.
  • Describe any problems encountered, previous solutions tried and new ideas to try to solve the problem.

I have found that this works really well and allows me to contribute to the task at hand more quickly than if I had to ask questions to work out what is going on.

The story champion has the benefit of having been involved in the story kick off so it is certainly very useful for them to be able to take this information and then provide it with context to their future pair.

In addition I have noticed that explaining what you are doing on a task to a new pair often leads to you noticing flaws in your logic, therefore leading you to solve the problem.

Even if this doesn’t happen, having a new pair of eyes and a new perspective on a problem can often lead to it being solved more quickly.

Written by Mark Needham

November 4th, 2008 at 12:00 am

Posted in Pair Programming

Tagged with ,