What if we told you that when developers in your company share their computer, they increase their productivity and decrease code errors? Sounds strange? Let us explain more about Pair Programming.
So, What is Pair Programming?
Pair programming is a concept where two developers use just one machine to work, meaning they work simultaneously on a single block of code. This brings in the concept of pair programing roles - While one acts as a driver (writing code), the other will play a navigator’s role (ensuring the accuracy of the code). The two developers can switch roles at any time of the process.
We can assume you must have a long list of questions by now. Stay with us as we walk you through the entire process in detail.
You may be wondering why waste a resource in getting the job done by two when it can be taken over by one, right? It might come across as a misuse of valuable resources but according to the Association for Computer Machinery (ACM) and the University of Utah’s Computer Science school, while the pair programming technique can take 15% longer, it also ensures 15% lesser defects.
Pair programming was first introduced to an extreme programming software development technique by Kent Beck in the ’90s. Extreme programming is an “agile project management methodology that supports frequent releases in short development cycles to improve software quality and allow developers to respond to changing customer requirements.”
According to Beck, “Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team’s practices. Pairing”
Benefits of Pair Programming?
The adoption of pair programming has received mixed reviews from across the developer's fraternity. The statistics above would have already set the tone. However, some agile development organizations prefer to take the pair programming approach for its common advantages.
Bug and error reduction
We had already shared the ACM report, which shows that pair programming results in 15% lesser defects. With two heads on the job – the driver and navigator – the codes are checked for accuracy in real-time and typos, bugs are identified on the go.
Cost-effective
The common misconception is that pair programming is often more expensive. Yet, just assuming the cost of two resources would not be ideal. One must remember that while bearing the cost of two developers, the overall time consumed on the project will also be relatively lesser when compared with the time taken by a single developer to do the same job, who would take lesser time making corrections.
Increases team’s knowledge level
Pair programming leads to better sharing of knowledge across the development team. A relatively new coder, while working with a subject matter expert can gain expertise faster as opposed to when working in silos. Similarly, several other such team collaboration enhances peer-to-peer learning.
Increases job satisfaction levels
Another research report – Strengthening the Case for Pair Programming – suggests that 96% of pair programmers preferred to work in teams and enjoyed the company of another programmer. It is known that when working in teams, professionals get a boost to their confidence levels and enhances their networking skills. In fact, over a period of time, enhanced teamwork improves the overall quality of work.
Why is Pair Programming Better than Code Reviews?
Code reviews are reviews of code written by a programmer to find defects and deflections. This process ensures that the testing of the codes is combined with quality control and improves the overall result.
However, where most teams face challenges is identifying a resource to just check another programmer’s codes and understand the reasoning behind them. The process is tedious and is often tested only when new functionality is added to an existing code.
However, with pair programming the entire process shifts. Codes are reviewed in real-time and both programmers can switch roles to keep the momentum alive.
Best Practices for Pair Programming
- Set rules: Even before implementing pair programming, establish the rules and present it to the whole team.
- Take it slow: While kickstarting pair programming, we suggest that you not to start with a sea change in developers’ work. Start with a few a few hours a week to try out the new method, see if it works for you and scale it up based on results.
- Analyse pair composition: Consider which pair will complement each other, as well as who can learn the most from whom.
- Change pair compositions: It is seen that when two programmers work together longer than a few sprints, there decrease in productivity and a risk of conflict. Hence it is suggested to change the programming pairs regularly.
- Plan pair programming before the sprint starts: The best way to effectively organise pair programming is to carefully plan both staff compositions and responsibilities when planning a new sprint. After analysing the status of individual tasks, it is the best time to determine who will work with whom, what the pairs should do, as well as who will be the driver and who will be the navigator, and how long will it last.
- Pair programming online for remote working: Gone are the days when Pair programming involves two developers physically being in front of the same computer. Online pair programming is gaining traction and though the numbers are yet to emerge, there is an opinion among the developer community that pair programming online is more productive than in person.
- Gather team feedback regularly: Regularly collect feedback from team members on how they find working in pairs. Common discussions and conclusions allow you to find the best solutions tailored to the company’s current needs and employees’ preferences.
List of Pair Programing Tools:
All the pair programing tools that we have listed fall into one of the categories below:
- Collaborative integrated development environment (IDE): This type of tool lets users invite other developers to collaborate directly in their IDE. Only the IDE is shared in this category.
- Single user sharing, dual user remote control: Tools that allow a single user to share their screen while the second user can view and control the screen.
- Multi-user sharing, multi-user remote control: Here, multiple users can share their screens and control apps at the same time. This category offers the most collaboration between the coders.
- Live Share (VS Code)
- Replit
- CodeTogether
- Teletype (for Atom)
- Tuple
- Screen.so
- Drovio
- Motepair by Atom
- Microsoft Visual Studio Live Share
- CodePen
- Codeanywhere
- USE Together
- Remote Collab for SublimeText
- CodeSandbox Live
- Cloud9
- Brackets
- Codeshare
- Coda
- Codenvy
What Are the Pitfalls of Pair Programming?
Okay, so let’s be honest, not everything can be rosy! While we have listed the benefits of pair programming, there is no doubt there are pitfalls too and we want to ensure you are well-informed before you can decide on whether pair programming will work for you.
It is expensive!
It cannot be simpler than this. Two programmers on each code are bound to increase the overall cost of the development work. However, considering the scenario as explained in the pros, the overall cost is often less than double.
It can be counterproductive
Pair programming is often called “programming out loud” and even though communicating through the entire programming process may seem to be a good idea, more often than not that’s not a strength for a lot of developers. Not all programmers can express themselves equally.
Additionally, varying experience levels may slow down the more experienced one to maintain pace. Assuming that all developers will be comfortable working on shared machines may be counterproductive.
Innovation and creativity may take a hit
Imagine if a pair of programmers don’t get along or don’t carry a similar thought process. Not being able to assess the partner’s skills and gain trust may lead to lost innovation and creativeness. It could also lead to conflict between the two developers if they are not in line with each other’s process. Additionally, varying experience levels may demoralize the other programmer from expressing themselves fully.
Pair Programming Styles:
Pair programming is a lot more than outing two developers to work together. Since its inception practitioners have been continually working to develop models that would work in different scenarios. Practice and experiments have been improved and these techniques have been refined to suit requirements. Here are a few methods adopted while pairing.
Driver-Navigator: This is the most popular and commonly used method in pairing. As explained earlier, the two programmers take the role of a driver and navigator respectively. Both need to interact consistently and also switch roles to keep the interest and momentum alive.
Ping-pong: This approach needs two keyboards connected to the machine, enabling both the driver and the navigator to work in quick turns. The first person writes a failing test and the second person gets it to pass, followed by the second person writing a failing test and the first person gets it to pass. This process works exceptionally well between two experts.
Backseat Navigator: This is typically adopted when the driver is relatively less experienced than the navigator. The navigator takes the backseat and instructs the driver on how to solve a problem and also reason out why the solution is the best option. This especially works well for newer team members.
Tour: This could be opted for in-between an ongoing process. For example, if the navigator from a pair were to leave the project mid-way, a new resource will be pulled in, who will now act as a driver and take a tour of all the details. Whereas, the other person will become the navigator because they have a deeper understanding of the code.
Distributed pairing: A setup where the two programmers are connected virtually to work on a code, rather than working face-to-face as practiced traditionally.
These are not the only pairing methods. Development teams could also choose pair programming styles that align with the skills of the programmers involved. Potential skill pairs include:
Expert/expert pairs: Two experts can generally work within any pair programming style. Advanced programmers may prefer the ping-pong style, as it allows them to have even participation.
Novice/novice pairs: Two novices together may have difficulty in the driver/navigator style, because no one is experienced enough to take charge. In addition, the unstructured approach may be difficult for beginner programmers.
Expert/novice pairs: The most common skill combination is an expert programmer working with a less experienced person. Experts rely on their depth of knowledge to direct the activity, while the novice can learn more from the expert.
Remote Pair Programming
Remote pair programming developers work together using a variety collaborative tools such as real-time editor, shared desktops or a remote pair programming integrated development environment (IDE).
How to use Pair Programing effectively?
The simplest way to start pair programming is by partnering two developers and letting them build the architecture, code and then effectively test each code in the true sense of a partnership. The most ideal way is to have both programmers of the same expertise level however, in the case of newer resources in the team, it would be ideal to pair them with someone with greater experience. And most importantly, ensure that the programmers switch roles often.
Integrating Pair Programing in Software Development Plan
Pair programming has its pros and cons but it works wonders in teams that have a higher tolerance and can think deep. The trick is to keep differences at bay and play on each other’s strengths to code accurately. After all, two heads are better than one!
