Pair Programming
Pair Programming is a highly debated topic on whether it’s beneficial and is worth the effort undertaken to apply this practice.
In this blog, we will discuss this topic including its different practices, benefits you will gain if you apply it, and challenges you will face when introducing it to the team as well as how to get the most out of it.
Pair Programming
Let’s start with a metaphor to grasp what pair programming is in the first place:
Consider yourself in a situation in which you’re driving to a destination that you know but you don’t know the exact route you’re taking, and you find yourself driving in a crowded area dealing with a lot of unexpected situations while using a navigation app to get to your destination!
Now wouldn’t it be nice if someone was beside you dealing with navigation and guiding you through the way letting you focus on the road avoiding any distractions and therefore any unexpected events!
That’s what pair programming is all about it’s about 2 people collaborating to reach a common destination these people are called a driver and a navigator.
The Driver
The Driver is the one holding the keyboard responsible for the coding, thinking out the details, the technicalities, and the lines of code at hand.
The Navigator
Navigator is an observant, the bigger picture person, the one responsible for thinking things through adding direction for what’s to come and reviews the code on the go
And much like the car metaphor our Driver and Navigator share the same space they use the same machine for coding whether physically or using screen sharing apps if virtually.
Despite this classification, these roles aren’t exclusive for each individual instead the pair should switch their roles frequently.
This classification leads us to have two focused modes of thinking, two perspectives on the code leading to overall increased quality as we will discuss later
Other Practices while Pair Programming
Pair Programming isn’t just a Driver-Navigator model there are some practices and variations that can be applied:
Unstructured Pairing
It’s what most people go for when they find themselves working on a task together, the term pair programming isn’t used explicitly, and the Driver-Navigator model isn’t applied as it is. This practice tends to be more spontaneous and could be less or more effective depending on the people working on the task.
Ping Pong
In this practice, we combine Test-Driven Development with Pairing
It goes as follows:
- First-person writes a failing test; a ping
- The second writes code that makes this test succeed; a pong
- Refactor code and execute tests again
- Once the task is completed, they switch roles and iterate the same way on another task
Pairing For Knowledge Sharing
This practice is best applied when you want to spread information among your team members for different reasons such as:
• Introducing a team member to a technology they have no prior experience with
• Onboarding a new team member to a project they just landed
• Sharing expertise from seniors to juniors by pairing them together
Pair Rotations
By using this technique, you can extend knowledge sharing amongst your team members; you simply have to rotate people on the same task by replacing one of your pair with a fresh team member, the one who was originally working on the task have to onboard this new member and then they can start pairing together. keep rotating pairs to share information with more of your team members but be aware not to rotate too frequently leading to time waste.
Pair Even More
Pairing doesn’t have to be while writing code only; You can pair people together on different stages of your story; starting with gathering requirements up to documentation. this will lead the developers to be more engaged in the story and its development process.
Benefits you will gain from Pair Programming
Pair Programming has many advantages that make it a strong practice starting with having a more coherent team to having a better-quality output, let’s Iterate some of them here:
Knowledge Sharing
Pair Programming plays strong in this area as you will:
• Avoid knowledge silos on solo tasks as more people start working on it thus, you will avoid team blocks if someone who was working on a task isn’t available, saving your project time.
• Sharing technical knowledge, information, tips & tricks, expertise and different skills among the team members leading to a more informed team and less codependency between the members
Code Review on the Go
As two people are working on the task, code is being reviewed by a second perspective while it’s being written which will lead to finding defects faster than one person only. This will lead to better consequences as this early error detection allows for more flexibility for changes than finding it later and having to implement some code again which will lead to fewer modules being revisited to be fixed.
And also, part of the code review process is to comply with standards, and we know we are all humans, and we can drift off leading us to write something like “Var x = 10” which we all know isn’t a clean code type and won’t comply with the usual standards, so having someone besides you will help you gain focus and avoid this.
Increased Product Quality
When applying pair programming you will notice an increased quality in output product and it’s not just because of error detection and code review it’s the discussion people have together on implementations, methodologies and technologies used, it leads to people selecting the best ones based on their discussions rather than their own judgement alone.
Team Collective Code Ownership
Having more people work on a task especially when applying pair rotations transforms tasks from being a “my thing” to be more like “our thing” thus increasing team spirit between its members.
Output Oriented
Pair Programming is output-oriented. You work together to achieve a goal, so pairing together will help you focus on that goal as we often get distracted by an idea or an approach that we are not sure of.
This will lead us to spend hours on that approach which may not achieve the end goal, having someone beside you will help you discuss approaches with them ruling out any distractions or far approaches.
Misconceptions About Pair Programming
There are multiple misconceptions about Pair Programming; productivity being the most common concern about it. Let’s discuss these misconceptions together:
Pair Programming reduces the productivity of developers
This could be assumed to be true if you assume the development of a requirement to be typing code only not putting into account the bugs and logical errors that could and will occur.
Having a pair work together as we saw in benefits sections reduces error and allows for code revision meaning that the time to revisit a published code will be greatly reduced or even terminated sometimes which we know takes quite the effort and time of the development process.
Pair Programming is not fun and likeable task
Sometimes people would assume that pairing would be an exhausting and cumbersome task while this may be true for certain situations, it’s a rare case a lot of surveys has been conducted and people who performed it actually liked it.
Pair Programming is best for new developers only
While it has huge benefits for juniors, pair programming is actually suitable for all experience levels; there’s always more to learn and it’s not just the technological hacks and tricks, it’s the thought process and collective thinking you practice together.
You can get the same results without pairing
It’s hard actually to get the same results for individuals as with pair programming as we discussed earlier the thought process and the discussions of the pair often lead to increased product and code quality which wouldn’t actually exist for individuals.
You have to do Pair Programming if you’re doing Agile especially if applying Extreme Programming
While it’s preferable activity, Pair Programming is just another Agile practice that is by choice and mandatory at all.
Obstacles that may halt Pairing
We are all humans after all, and we cannot waive the human factor of pairing as we all know we have our differences as humans.
This will come to play when sharing the same space with a person and working together on the same task so some inconveniences may happen as follows:
• Having to communicate with someone for long durations could be tiring especially for introverted individuals
• Having different mindsets, communication styles, working preferences, and skill levels could lead to frictions between people or impatience when someone is working at a slower pace than the other
• Receiving feedback especially negative ones don’t always feel comfortable and it may play on an individual’s insecurities
• Peer pressure may affect people’s work it may lead to people working long times without breaks being shy to ask for one, it may also lead individuals to be anxious when coding
• Different people schedules may affect people’s time when pairing especially when they have meetings for example
• Needing time for yourself is an essential part of work-life; taking it for learning, researching, ...etc. it may not be feasible if the pairing is forced or when you have a long task at hand that you need to finish together
Some recommendations to get the most out of Pairing
To get the most out of Paring there are some actions you need to take and some to avoid, here is a list of these actions:
More recommendations:
• If you are pairing to gain knowledge from a partner, get to know the topic briefly beforehand
• If paring with junior let them play around and discover errors on their own before correcting them immediately
• Reflect on the results of your pairing session and celebrate your achievements together
Conclusion
Despite having its concerns and obstacles Pair Programming is one of the most beneficial practices you can introduce to your team its advantages and gains outweigh those concerns.
It will lead to having a more agile team and increased product quality and time gain in opposite to what people may see as a time and resource waste
.webp)
.webp)
