Mark Needham

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.

In order to experience the full benefits of pair programming it is important to try and reduce the chance of the navigator getting bored and losing focus.

One of the main ways that we can do this is by ensuring that we have a quick turnaround between the driver and navigator, and this can be done by ensuring that when we are driving we are doing so as quickly as possible.

There are three areas that come to mind where we can gain speed improvements when driving in a pair programming session:

IDE shortcuts

Learning the IntelliJ shortcuts was one of the first things that I was encouraged to do on the first Java project that I worked on at ThoughtWorks.

I found the most effective way for me was if my pair pointed out potential shortcuts whenever I was using the mouse to try and do something. On my current project we have installed an IntelliJ plugin called Key Promoter which pops up a message telling you the shortcuts every time you use one of the menu options. I learnt about this plugin from Neal Ford’s book, The Productive Programmer.

Additionally there are PDFs available, which list every single shortcut available for the various different platforms, on the IntelliJ documentation page.

The same applies whether we are using TextMate, Visual Studio + Resharper or any other IDE. Knowing the shortcuts allows you to execute tasks more quickly and (for me at least) also has the benefit of making you feel more confident about what you are doing.

IDE templates/Plug ins

Setting up templates for frequent operations is another useful way to save time.

In particular I find it especially wasteful to write out the code to define a JUnit test every time so I always create a template which does this for me.

IntelliJ also provides a set of built in templates for creating simple code snippets – accessible by using the Command + J keyboard shortcut on the Mac or Ctrl + J on Windows.

In addition we can install plugins which help us to be more productive. TestDox is one such plug in for IntelliJ which allows you to create the test class for any class with one keyboard shortcut. We can then switch between the test and the code using the same shortcut.

For Ruby, RubyAmp is a TextMate plugin which I have come across which adds class, method and whole project searching for Ruby code.

The Shell

Using the shell or command line effectively is another way that we can can speed improvements.

I wrote about some of the ways I have learnt for doing this and several people provided other suggestions in the comments on the post, but the key pattern here seems to be to reduce the amount of typing and avoid repetition. It’s all about reducing duplication of effort when it comes to using the shell effectively.

Often when using the shell we want to reuse some of the commands that we have entered previously.

I was aware of two ways of doing this until last week – using the up and down arrows to go through the history and searching through the history using Ctrl + R.

A third way I learnt last week was to type the following command into the shell:

history

This returns the list of items that we have previously searched for:

 533  man grep
 534  grep -r "JarTask" *.*
 535  grep -r "JarTask" .
 536  cd java/

A colleague showed me that we can repeat these commands by typing ‘![NumberOfCommand]‘. To repeat the ‘man grep’ command we would type the following:

!533

Spotting patterns of repetition is also useful. For example, to redeploy our application for manual CSS testing we had several steps which involved stopping Tomcat, redeploying our WAR, updating the database and then restarting the database.

This involved 4 separate commands until one of my colleagues put it all together into a simple ‘restart’ script. Quite a simple idea but it reduces human effort.

Overall

These are some of the ways that I have noticed where we can make pair programming go more smoothly and keep both people on the pair engaged.

The common theme is that we should make our tools do the work and save our time for thinking.

In an earlier post about Team Productivity I stumbled upon the idea that while pair programming there could be such a concept as pair flow.

The term ‘flow’ is used to describe a situation where you are totally immersed in the work you’re doing and where time seems to go by without you even noticing.

This can also happen when pair programming and I think there are some factors which can make it more likely.

Code Intuitively/Making the IDE do the work

Coding intuitively was one of the first things I was taught by one of my colleagues when I paired with him nearly two years ago.

The idea is that you should code in such a way that your pair can clearly follow your line of thinking based on watching what you are typing. This includes naming variables, methods and classes in a way that communicates their intent.

In addition, we need to make the IDE do most of the work – this means creating variables by typing in ‘new MyObject()’ and then getting the IDE to handle the assignment for example.

One of the easiest ways to get out of a state of pair flow is to manually type everything – the navigator will lose focus much more quickly and as a result of this possibility it becomes vital that experienced users of an IDE share their knowledge on the shortcuts with other team members.

Test Driven Development

Using a TDD approach makes it much easier to get into a state of pair flow because there are lots of little goals (i.e. passing tests) that we can achieve along the way which helps to provide a structure around the work that is being done.

The times when I have experienced pair flow have been when I’ve been constantly engaged in design discussion followed by implementing the ideas derived from these discussions.

One of the most effective approaches that I have used when combining pairing and test driven development is ping pong programming – one person writes the test, the other makes it pass, they they write a test and the original person makes it pass.

The benefit of using this approach is that it allows both people to remain focused on the story being worked on, and also provides a useful way to drive out the design.

Constant Communication

Talk, talk, talk!

There’s nothing likely to make pair programming painful than a lack of communication between a pair.

I’ve noticed that pairing seems to be at its most effective when the driver is not only coding intuitively but also explaining their thought process along the way. I have lost count of the number of times that I have been describing how I’m planning to do something and my pair points out a better way of doing it.

As a navigator don’t be afraid to ask questions or make suggestions about how to improve the code being written.

Communication doesn’t only have to be at the work station either. Going to a whiteboard and sketching out a design to confirm a dual understanding is equally important.

Sufficiently challenging problem

If the problem being solved is very easy or very boring then pair flow is not going to happen because both people are not engaged.

I posted earlier about some of the situations where there might be some doubt over whether they are suitable for pairing and I think it is important to make sure there is value in what we choose to pair on.

The best tasks for concentrating both people in a pair are ones where there is some complex business logic to implement or where there are significant design decisions to be made in the implementation of a piece of functionality.

In the comments of my previous post on pairing Vivek made the following comment about when we should pair:

The simplest principle I have is to use “conscious” pairing vs. “unconscious” pairing. A pair should always *know* why they are pairing.

On previous projects I have worked on there have been several tasks where it has been suggested that there is little value in pairing. I decided to try and apply Vivek’s principle of knowing why we might pair on these tasks to see if there is actually any value in doing so.

Build

The value from pairing on the build when its in its infancy shouldn’t be underrated – the build plays a vital role on projects – providing a decisive point of success or failure for the running of our code.

I have worked on teams where the velocity has plummeted due to a fragile build, eventually ending up in development being frozen while we put it back together again.

While I’m not saying these problems would be 100% avoided by having a pair working on the build – certainly having two people working on it (at least initially) helps reduce the possibility of crazy decisions being made.

If it’s not possible to put a pair on this then at least ensure that the approach being taken with the build is well communicated to the rest of the team so that suggestions can be made and then applied.

Verdict: Pair initially to get it setup. Maybe work alone for small fixes later on.

Spiking

I have noticed that there are two types of ‘spiking’ that we typically end up doing:

• Spiking to work out how to use an API to solve a problem
• Spiking various different options to solve a problem

If the library to investigate is clear then it may be more beneficial to take a pairing approach. I have worked with colleagues before who had a much different approach to working out how an API should be used than I did and our combined approach has led to quicker understanding than working separately may have done.

When we need to investigate a lot of options then this investigation will certainly be completed more quickly if a pair splits up and investigates the options between them before coming back together to discuss their findings. When this initial (brief) investigation has been done then I have noticed it works quite effectively to revert to pairing to drill down into a specific library.

Verdict: Decide based on the spiking situation

Bug Fixing

If we’re doing our job properly as agile developers bugs should be relatively easy to pin down to a specific area of the code.

For these types of bugs the value of taking a pairing approach is that we’ll probably write a test to prove the existence of the problem and from my experience we get better tests when pairing.

An approach taken on a previous project was to have one pair focused on bugs and just going through them all until we cleared out the highest priority ones. Another interesting part of this for me is that I would normally consider bug fixing to be very boring but when done with a pair I actually quite enjoyed it and it was often fun hunting down problems.

Verdict: Have a bug fixing pair to clear out high priority bugs

Writing Documentation

Despite working in an agile environment there are times when we need to write some documentation – whether this be writing some information onto the Wiki regarding use of APIs or creating architecture diagrams for discussion.

This is one area where I feel there is actually very little value in pairing. We tried to pair on this on one project I worked on but the navigator often found it to be very boring and we saw more value in one person driving the initial document and then someone else reviewing it afterwards.

Verdict: Don’t pair

Release or Deployment Tasks

This has often ended up being a task taken on by the Tech Lead or a Senior Developer in previous teams I have worked on.

A lot of the work is similar to writing documentation for which I would advocate a non pairing approach but have someone else look over the release document before sending it out.

However, knowing the production environment and how it all fits together is useful information for other members of the team to know so there may be room for some pairing for part of this process.

This way if/when problems arise in production and the Tech Lead isn’t around the team will still be able to address them.

Verdict: Don’t pair for the documents but maybe for other parts of the process

That’s just some of the grey areas of pairing that I could think of from a quick brain storm. I’m sure there are others too.