Pair Programming – what to consider when implementing it? - Questers

Pair Programming – what to consider when implementing it?

Pair programming is a software development technique that has certain setbacks, however if implemented carefully, it could bring significant improvement in terms of productivity, code cleanliness, social interaction and knowledge exchange across your development team.

Having a number of teams applying this method in various types of projects, we have researched and analysed the red flags of the process and how to take the best out of it. Our research showed that the successful outcome of the pair programming is strongly dependable on a number of factors such as complexity of the development task, seniority and persona type of the participants, etc.

Let’s take a closer look at some of those.

Complexity of the development task

Let’s be fair - not every project is suitable for pair programming. When it comes to complicated dev cases, two heads think better than one. And this is where pair programming would do a great job. It is ideal for solving issues that require a broader knowledge and complex logic. Respectively, when dealing with a simple task, probably there’s a better way to distribute your team’s time.

To avoid inefficiencies, make sure you distinguish the simple tasks from the intricate ones and assign them accordingly.

Seniority of the participants

Another thing that should be taken into consideration is the level of seniority of the participants. There are a few pairing variations that come along with their positives and negatives:

  • Senior – Senior. This combination may seem like the most productive one, but in fact, it has its drawbacks. Surely, it could lead to great results, but often senior developers are prone to strictly follow established practices and are not keen to search for alternative ways to solve a problem. Moreover, in this type of pairing, there is little space for knowledge exchange.
  • Senior – Junior.  This type of pairing stimulates knowledge transfer and is more likely to produce new and creative ideas. Surely seniors have a lot to educate juniors but on the other hand, they also have what to learn. Juniors are more likely to doubt established practices and when required to explain them seniors could also reassess their value.
    Here the drawback is the threat of the “follow the master” syndrome, where less experienced developers are afraid to question seniors. This way the generation of new ideas is limited and it is actually your senior dev that is doing all the work.
  • Junior – Junior. Pairing two juniors may lead to better results than leaving them working on separate tasks but usually, this combination is not recommended. Thinking outside the box is always encouraged but without an experienced person to discuss and evaluate the solutions with, juniors could easily get lost and produce even more complicated and unnecessary code.

To select the proper pairing type, make sure you carefully evaluate the task and people you are planning to involve. When pairing senior and junior programmers make sure the experienced developer is open to new suggestions and even encourages them. In this way, the junior will feel comfortable asking questions and will be actively involved in the process.

Personality traits of the participants

The successful outcome of the pair programming also depends on the people involved and their motivation. Collaborative people with good communication skills are a preferred choice, as they will find a suitable approach and will enjoy working with other colleagues. Introvert people probably won’t be very excited to work so closely with others and will not be as productive during the pair programming process.

When planning to integrate pair programming practice our advice is to start with your most proactive team members. Involve two or three pairs and let them work on different projects and then share their experience with the rest of the team. If the feedback is positive, it may attract the more reluctant people and gradually engage them. If the transition to pair programming is steady and not applied as a must-do procedure, it will help team members find the best way of implementing the method and establish their own principles of work.

In conclusion, pair programming is a useful technique that requires careful assessment of many factors in order to be successfully implemented. But once established with the active participation of the team members, it could generate remarkable value for the company and for its employees as well.