How we code in pairs

At Friendsurance, we are doing extensive code reviews and unit testing of all code. On top of it, we started to experiment with pair programming.

There are a lot of companies which are doing pair programming, some are doing 100% of that!

It’s debatable if pair programming is good or bad, however I see a lot of reasons why it can improve quality of our product/code.

I believe, that in Friendsurance we have people whose approach to software development works very well in pair programming. Although we don’t have plans (yet) to transition to pair programming, but we already see it working.

Here is how we organize pair sessions

  1. We work on a single machine.
  2. There are two roles in the session
    • The one who is doing active coding.
    • The one who is leading the session.
  3. Each active session lasts 30 minutes which follows with 5 minutes break.
  4. After on active session - we switch the roles. The one who was coding starts to lead the session, the other one starts active coding.
  5. After 4 cycles, we do 15 minutes break.

It’s more or less following Pomodoro techniques with few adaptations to our needs. We don’t have yet precise measurements if this is effective for us or not, however I’m sure on one thing - I’m more productive and feel happier in pair! Beside that, I see the following pros and cons so far.

Possible Pros:

  1. Effective / runtime knowledge sharing.
  2. Forced top-down approach in development - pairs always hold/discuss bigger picture first and go down to implementation afterwards.
  3. It saves you a lot of time! As there is always two pairs of eyes on code, you save a lot of time in code reviews and problems/defects are caught in early development phase.
  4. Increases trust between team members.

Possible Cons:

  1. When the work to be done is straight forward, one of the pairs usually has nothing to do.
  2. One of the pairs dominates the other one, as a result there is not enough involvement during the session.
  3. It requires more energy - you need to talk to the pair, debate and argument on things.

I’m looking forward to observe how pair programming affects our development; meanwhile, happy coding :)

Written on January 10, 2017