Archive for the ‘pairing’ tag
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.
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:
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.
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:
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:
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.
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.
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.
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.
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
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
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.
My former colleague Vivek Vaid has an interesting post about parallel-paired programming where he talks about introducing lean concepts into deciding when we should pair to get maximum productivity.
Midway through the post he mentions that the original reason that we starting pairing was for ‘collaborative design’ which got me thinking whether there are reasons beyond this why we would want to pair.
I have often worked on clients where the value of pair programming has been questioned and it has been suggested that we should only adhere to this practice for tasks where it adds most value.
Clearly collaborative design is one of these, but there are some others too:
The idea here is that someone who has been on the project for a great amount of time (possibly the Tech Lead) can help bring newer members of the team up to speed.
They can help the new team member to get their development environment up and running (although clearly making this as automated as possible is beneficial!) and help walk them through the code covering any questions they may have.
This role may also involve going though the reason that the team is there (i.e. what problem we are trying to solve), an overview of the way the problem is being solved and the technologies being used to do so, patterns being used in the code and any other information that is considered useful to the new team member.
Using pairing in this context makes it much easier to get new team members up to speed, therefore improving their ability to be a productive part of the team.
Increasing Team Level
Pairing up senior and more junior members of a team is a very effective way to increase the level of the junior person.
More senior team members have a lot of knowledge which they can pass onto junior team members – as this knowledge comes from experience in the field it is not necessarily something that could be gained from reading a book.
On several of the projects I have worked on one of the more Senior members of the team has been the one who provided the onboarding for new team members.
Clearly there needs to be a balance with this approach because no matter how patient the senior person is, at some stage they are going to want to have the opportunity to work with someone closer to their level of ability.
Using pairing in this way helps to bring up the level of the less experienced members of the team and allows them to learn things that more senior members of the team probably take for granted.
This one is a harder one to sell because there are no doubt other ways of sharing knowledge on teams beyond just pairing.
However, I have seen it work successfully on projects I have worked on for spreading the knowledge of how different parts of the application work amongst the team. This is generally referred to as increasing the truck factor – no one member of the team should be invaluable.
I saw this as a benefit on a project I once worked on where I had spent the majority of our time pairing both with ThoughtWorks colleagues and client developers.
At the end of the project we had a meeting to discuss what handover needed to be done in order to allow the team to continue when we finished. We really struggled to find anything at all – the knowledge of how to do the vast majority of tasks was completely spread out amongst the team and no one person had knowledge that the rest of the team didn’t have.
This is almost like a side effect of pair programming but it definitely has some gains which should not be discounted.
Pair Programming vs Parallel Pair Programming
I’ve never used parallel pair programming, only pair programming which is used the majority of the time on projects I have worked on.
I would be interested in knowing whether we can still gain some of these other benefits from using parallel pair programming – it seems to me to be quite a streamlined version of pair programming, and I wonder whether we would still get the useful side effects of pairing if we don’t pair all the time?
When it comes to Pair Programming the Junior/Junior pairing is considered the most likely to lead to disaster. The old joke being that if you pair two Junior Developers together then you’d better hope you have a revert function on your repository. But is this fair?
Certainly pairing two Junior Developers together means that you automatically lose the value of the experience and mentoring skills that you would get if there was a Senior Developer as part of the pair.
Assuming that we’re working on an agile project, the biggest area of risk you have when doing this is the possibility that neither of the developers understood exactly what the story that they are implementing required and they end up going way down the wrong track and not managing to complete it in anywhere near the amount of time that was expected. Now clearly if this happens too many times then it could end up being a project risk, but if the project is being run well then I don’t think that this is necessarily a problem.
Pairing two Junior Developers together gives them both the opportunity to gain confidence in their own ability. There is no longer a Senior person for them to defer to when there is a decision to be made so they have to step up and make the decision between them. This is a crucial part of our development as there are always decisions to be taken, trade offs to be made, and the ability to deal with this is crucial in agile teams.
It is also often the case that the Junior Developers who have just finished at ThoughtWorks University have been very well drilled in the art of pair programming and putting two of them together actually results in a very effective pair. They may not have the experience of other team members but their enthusiasm and lack of bad habits means they can be productive.
Having said that it is useful to provide a safety net of sorts for the pair so that they do not end up struggling (and I’m not even saying that that will happen).
Before starting on the story it is even more important that Tiny Tasks are created for the story being implemented. I find this an indispensable tool and if you ever look at my desk it is peppered with yellow stickies of tasks that I need to do to complete whatever I’m doing. The breaking down of tasks is brilliant for a Developer of any experience level, but is particularly useful here as a Junior pair may not have experience of solving a similar problem before and having a task list will help to keep them on track.
It is also useful to ensure that there is a more Senior person in the team (usually the Tech Lead) available to offer coaching/guidance if it is required by the pair. They may not need to intervene very often but the pair should feel that if they do run into problems that there is someone with more experience ready to help them out.
Overall I don’t think this is a pairing combination that should be avoided, much to the contrary. The team should look for ways that they can help support a Junior/Junior pair and help them to develop their abilities so that them pairing together is not even an issue at all.
One idea which was suggested around the time I wrote those posts by my project manager at the time was developers pairing with the QA or BA on certain tasks. I didn’t get to experience it on that particular project but over the last week I’ve been doing quick a bit of build work and for some of that I was pairing with our QA.
Now doing build work might not seem an obvious pairing activity because it is often seen as tedious, and it can be quite boring for the navigator as it is harder for them to add obvious value. We decided on this occasion that because we had different expectations of the build that it would be worthwhile for both of us to work on it for the duration of a pairing session. It turned out to be a good decision.
The build pipeline that we were working on consisted of two stages when we started.
There was the main build which compiled all the code, ran all the tests, created all the artifacts, created a zip file for each artifact and then added an entry into the database for the artifact.
Then we had the functional test build which waited for this main build to finish before running its tests against the artifacts we created in the main build.
As a concept it worked reasonably well but it was becoming obvious to both of us that a lot of the functionality that I had put into the main build didn’t actually need to be in there.
We spent some time discussing how to fix this problem with me focused heavily on how we could reduce the time spent on this stages. We weren’t really getting anywhere until my pair made the breakthrough suggestion that we move all the actions related to artifacts into a common build which the main build could feed into and the functional tests build could depend on. The functional tests build would still be able to get everything that it needed and we were able to reduce the time of the main build by around 50%.
A vindication for pair programming indeed, proving that there is great value in having someone in the role of navigator taking a look at the bigger picture and seeing the obvious things that the driver may miss.
Clearly there are fewer opportunities to partake in Developer/Non Developer pairing because the roles have different focuses. I think in this example it also helped that our QA previously worked as a Developer and was therefore already skilled in several of the aspects of pairing. Adding this ability to his focus on the testing aspect of the build allowed us to come up with a better solution than if we had put a Developer/Developer pair on the task.
It would be interesting to see if our effectiveness would have been less had I paired with a QA who had never paired before. However, I will certainly be looking for other opportunities on this project where the other developers and I can pair with the QA on other tasks.
I am also particularly interested in the idea of pairing with a BA. I have never paired with a BA before but identified a possibility of this on a previous project where business specifications were being written using Concordion. In this situation I felt it would be useful to have a Developer pair with the BA to write the assertions as this required deeper knowledge of HTML than a BA would be expected to have. We didn’t get the chance to try it out on that project but I certainly hope to find the opportunity to pair with other non developers in the future.
It would be interesting to know if anyone has similar experiences with pairing.
One of the intriguing aspects of pair programming for me is that of the non driving person in the pair – what are they supposed to do?!
Obviously there are fairly well known strategies for more interactive pairing, such as Ping Pong and Ball and Board (which is where one person controls the mouse and the other the keyboard), but neither of these strategies suggest what to do when you are not driving
Obviously it is very easy to be a bad non driving part of the pair, by getting distracted by what’s going on around you and a quick fix that I’ve heard to solve this is that when you’re bored, ask for the keyboard back. This solves the immediate problem but still doesn’t make you any better at contributing when you’re not at the keyboard.
One idea that I’ve been playing with recently is keeping a list of the next task that needs to be done after the current one is done – effectively just tracking where we are on the story. We use tiny tasks for most stories as laid out by Patrick Kua. This does work although you still don’t feel that involved, and it can end up seeming like you’re dictating to the other person what to do. This is definitely an approach to be applied with some tact.
Some of the more skilled non drivers I’ve worked with have the ability to see the bit of code being worked on as part of the whole and are able to see when we have gone too far down the wrong path and should actually be making changes elsewhere. I find this a lot harder to consciously improve, and I’ve been told it’s a skill that comes with experience.
I’m sure there are other roles of non driving that can be applied, mentoring being one, although that’s for another post! Thoughts?
I’ve had the opportunity to have worked with many different people pair programming wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.
First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.
Obviously I do not know every IT organisation in the world, but based on discussions at the ALT.NET UK conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.
I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.
I’ve paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it’s been fun.
I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.
The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a ‘wrong’ idea would have to somehow make sense to two people, which is much less likely to happen.
Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.
On the flip side there are times when you just want to look up something which interests you but isn’t totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.
I will cover some of my other thoughts in future posts.