Archive

Posts Tagged ‘pair programming’

Pair Programming Anti-Patterns

February 19, 2010 Comments off

I read an interesting blog post by Mark Needham today that talks about some anti-patterns he found himself falling into while pairing. I have also caught myself being guilty of some of these offenses so I thought that listing some here explicitly will help keep it fresh in everyone’s mind. Of coarse what works some may not work for everyone, but here is a small list of behaviors I which I find can negatively impact pair-programming…

Moving around the code too quickly

As the driver, it is normally a bad idea to be changing windows/files/tabs/etc. too quickly while you are in control of the computer. It is easy to forget that your navigator may not know what you are thinking so you find yourself flying through the UI of your workstation at lightning speeds only to have your pair say “Ok… what just happened?” Granted, following a driver’s every keystroke is not the navigator’s concern, I do find it helps collective code ownership to have the navigator pay attention to what the driver is doing. Therefor, I believe that it is always a good idea to communicate to your navigator what you are planning to do BEFORE doing it which also give them the opportunity to offer any input they have before everything has been said and done.

Grabbing the keyboard away

This one is a little more obvious as to why it is an anti-pattern but let me elaborate anyway. My opinion is that it is NEVER a good idea to take control of the keyboard and mouse without asking first. I have seen it happen for various different reasons; lack of time, lack knowledge, lack of patience, lack of discipline, and lack of respect. Sometimes you just want to finish your task and you know you can get it done quicker or maybe you are really excited about trying to solve the problem and hand and anxiously snatch control of the computer. Sometimes the guilty may have all of the above reasons for this behavior but I don’t think it should ever be acceptable. By taking control, you are giving your pair the impression that you think they can not accomplish what needs to be done or that you can do it better. It is always a good idea to ask first before taking control and if the driver was in the middle of something, you’d better have a good reason. This also promotes better communication because you more often have to attempt to explain your ideas to your driver instead of just doing it yourself.

Vacationing as the navigator

Pair programming often come with negative connotations because some ask “Well what can/should I really do as a pair?”. The reality of it is that pair-programming involves two distinct roles each with their own very engaging responsibilities. The driver is tasked with controlling the workstation to write the test cases, code, and refactor. The navigator should be involved with design decisions made while writing the code but they do not necessarily have to be reading every line of code the driver writes. Instead, they should be thinking of what test cases come next, whether or not the existing tests are passing, can we commit, and most importantly: “Are we done yet?”. This is why it is very important to not become detached from the task at hand while your driver tries to figure out where he is missing a semi-colon. Distractions like mobile devices, food, twitter, etc. can often lead the the navigator not having a plan which leaves both people in the pair asking “What next?”. This is not to say that a driver cannot become distracted as well but, in my experience, I have found it harder to fall into the trap when you are the one engaged at the keyboard and much easier when you can literally twiddle your thumbs. Just remember you are there as a supportive role to your driver and they are lost without your “map”. To help avoid this, it is a good idea to make sure you are switching roles often to keep both people engaged in the task at hand.

You can check out the original blog post which inspired this one here.

You can learn more about pair-programming here and here.

I am also interested if anyone else has any other pair-programming anti-patterns they would like others to be aware of. What do you find negatively affects a pair-programming situation? Or for that matter, any tips on how you have become more effective? Feel free to share!

Mixing Up the Pairs and Collective Code Ownership

May 1, 2009 Comments off

During my current team’s daily Scrums we’ll finish up by organizing our day.  It is usually pretty obvious what stories we need to be working on based on the state of the Scrum board, but who should be working on them is not always so clear.  During the lifetime of a story (which most often is multiple days) I will start to get uncomfortable if it has been worked on by the same pair.  As the Team Lead I’ll raise the question, “should we mix up the pairs?”

As a team we are striving to attain collective code ownership.  We are close, but not quite there.  In order to get there as fast as possible,  I feel that switching pairs often is one of the answers, but in the early stages this can be difficult and exhausting.

The previous team I led did reach a level of collective code ownership.  We committed to switching pairs at least twice a day, and facilitated this by introducing a mid-day stand-up to reorganize the team.  We would also use this time to discuss the progress of our current stories, before getting back at it. Our experience at the time revealed the following pros and cons.

Cons

  • lots of time spent “ramping up” a new pairing partner after joining a story in progress
  • developers could become frustrated having to give detailed explanations to new pairs multiple times per day
  • it was very draining for developers to have to switch contexts so often

Pros

  • better design resulted from multiple developers being involved in the story
  • developers were seeing all areas of the code
  • the team was suppressing the creation of “experts” for certain areas of the system. Everyone was an expert – our truck number was rising.
  • daily Scrums were becoming more useful since everyone understood the stories being discussed. No one had that glazed look on their face waiting for their “turn to report in”
  • our velocity started to increase

The process was not easy, but as we pushed forward we found that the time to get brought up-to-speed gradually got shorter.  During the daily Scrums our discussions were now leading the developers to form the pairs on their own in a more natural fashion.  And before we knew it they were switching pairs outside of our daily Scrums whenever they felt it made sense.  That’s when I realized we had collective code ownership.

Like I mentioned earlier my new team is still working towards collective code ownership so I am trying to implement some of the steps my previous team took.  The team is larger, and we are working with a bigger and more diverse code base, but I am confident that we will reach our goal.

I am interested to hear about others people’s experiences in this area.  What measures did your team make to maximize your truck number?  When do you think it makes sense to switch pairs?

By Hemant J. Naidu