Modern software development teams are geographically distributed. The best talent for your company may not be in the city you live in. While hubs like Silicon Valley (San Francisco), Silicon Alley (New York) & Silicon Roundabout (London) are home to some of the highest concentrations of software developers in the world, there are equally thousands of developers spread across the planet that can be tapped with the right process and tools.
Primer on Pair Programming
Knowledge is commonly socially constructed, through collaborative efforts toward shared objectives or by dialogues and challenges brought about by differences in persons’ perspectives. — Salomon
Conceptualized in the early 90’s, “pairing” was intended to improve the communication & quality on projects. Some studies have shown that while the overall man hours required to ship code while pairing increases, the number of defects in production can be lowered, by up to 15%. Alister Coburn, the founding father of the Agile Manifeso publishes some interesting statistics in his seminal white paper, The Cost & Benefits of Pair Programming.
Benefits of Coding Together
Software development is ultimately a human process. While we focus our craft around design patterns, code optimization and bits & bytes, in order to deliver a product we talk. We debate. We make jokes along the way.
Pairing is a medium for receiving instant feedback.
When your work is subject to review, mistakes are caught. Different perspectives drive alternative implementations. Change is good. The only constant in software is change.
Great managers give feedback, all the time. Positive & negative. Pairing allows managers to delegate and distribute the feedback model to the teams unto themselves. This is what we call scaling management. When you allow your teams to self govern themselves, quality increases. Morale increases. Your company culture starts to gain more karma.
Communicate Anywhere and Everywhere
Developing software together doesn’t mean you have to be in the same room. The modern office is moving to a remote workplace.
We have tools that can facilitate & communicate our thoughts to anyone around the world. The key to remote communication are to maintain frequency & verbosity. Team communication dynamics change when everyone isn’t in the same room together.
When you declare a decision in a room, that decision is heard and acknowledged. When you’re remote that decision needs to be written down and disseminated so that the entire remote team can acknowledge. This is especially important when you have a hybrid team where some members are on-site, and others are remote. The folks whom are remote need to have the exact same information as the folks on-site & vice versa.
Misinformation in an organization results in poor quality. The wrong requirements are written, or the implementation does not meet the requirements acceptance criteria. Nipping miscommunication starts with spreading information to everyone, no matter where they are located at the time.
Pair Programming Best Practices
Audio quality and video quality is crucial when you’re pairing remotely. Make sure that both parties aren’t on mute, can hear each other and have a non-jittery video feed going live.
Working across timezones can be difficult. Here are some tips to help coordinate a schedule for pairing:
- Pick the same time every day so the team gets into the habit of meeting
- If the timezones are vastly different then it is important to be respectful of each other and perhaps alternate times that are suitable for each other
- Put it on the calendar. Research shows that writing down appointments and using tools that remind you of appointments result in better timeliness.
Remember that pairing doesn’t mean that you’re stuck at the hip with your pair. It’s ok to go off the grid and take breaks. Again, communication is critical here. When you’re remote, notifying the other party that you’re going away from the keyboard (AFK) is a common courtesy.
- “Hey, lets take a 15 minute break, I’m going to grab some water”
- “Tomorrow I’m going to be out from 1:30PM-3PM, just wanted to let you know in advance”
- “Now that the design is clear, lets divide and conquer for a few hours and pair review since we have a deadline coming up”
- Going AWOL on Slack — when people are depending on you, its important to notify when you’re leaving
- “brb” — does not specify when you’re coming back. Be respectful to your pair so they aren’t waiting around for you
- “Lets take a break” — doesn’t specify how long. Both parties need to know
Dealing With Nervousness
Lets face it, it’s human nature to be naturally cautious when someone is watching over your back. Pairing is not intended for managers or others to see what you’re doing. It is in fact the opposite. Pairing is intended to provide a medium to communicate.
Shaking the nerves requires practice. Practicing pairing means showing up every day and discussing your problems. Whether they are code problems, setup problems, inter-personal team problems, you talk it out. The simple habit of discussing problems with your pair helps from a relationship, which can result in confidence.
Conflict Resolution for Remote Pairs
Guaranteed there will be times where a pair may not get along. An overly critical code review or a pair abandoning ship may ruffle some feathers. Whatever the reason may be, managers need to intervene and make sure that angst is minimized. This means rotating pairs, or coaching individuals to obtain a higher level of emotional intelligence.
Measuring Pair Programming Effectiveness
Pairing may or may not be right for your organization, so it is crucial that we track how effective the process is. A few KPI’s come to mind.
Like the Net Promotor Score, a Happiness Score can be a measure of how satisfied an individual contributor is.
- “How happy are you pairing on a Scale of 1–5 with 1 being Sad and 5 Being Ecstatic?”
- “Do you like working with <Person A>, Yes or No?”
Polling the team in a 1:1 setting and receiving positive feedback is an indicator of continuing the process. If the individual is not happy, or doesn’t like working with an individual pair, it will require further introspection. Debugging humans is not binary. The build will fail and may always fail. Pairing may not work for certain individuals and it is important to understand how they fit into the organization to be effective.
Shorter Time Spent During Code Review
Pairing should reduce the amount of time spent reviewing a Pull Request. In a pairing scenario, code is being reviewed instantaneously and therefore does not require the back and forth commenting of a pull request.
If you begin to notice a flurry of pull request comment activity, it may start to indicate that the reviews during pairing may not be working. Team members aren’t communicating, or not taking the effort seriously. Debugging this may require rotating a pair or understanding the root cause of such problems.
If the number of bugs start to increase after shipping a release, there may be a problem during pairing. The entire goal is to reduce the number of defects through continuous feedback and review. Bugs can be the result of poor code, or a poor requirement. Discussing code and discussing requirements is fundamental to the mutual understanding of the product.
Pair Programming Red Flags
Rallying together and trying a new process is fun and invigorating, however, if the team is not producing any results, we must debug the process.
Pairing is merely a process, and ultimately serves an even greater good; shipping value to the customer.
If release dates constantly slip, and milestones are not being met, this can be trailing indicator for revising and debugging the pairing process.
Pairs Abandoning Each Other
Captains of the ship must make sure that their crew is tight knit so that they can navigate the treacherous seas. A crew member that abandons ship reduces the overall output of the team.
Managers must watch out for pairs that are unhappy or don’t like working with each other. This means rotating pairs when times are tough, or coaching individuals to communicate better and more openly so there is a shared mutual understanding.
Complaints about Slowness
Folks who are new to pairing may say that they get work done better by themselves, or that pairing slows down the software development process.
Indeed it does, for the sole reason of communicating more to reduce risk.
Software is not measured by the lines of code written, or the number of features shipped. Software is measured by customers buying product, or being delighted by the experience.
More time spent designing, discussing and reviewing code instead of writing it, results in higher quality.
How to Roll out Remote Pair Programming to Your Team
If you are new to pairing and want to onboard your team, remember that change does not come without resistance.
Gradually rolling out pairing to the organization may be prudent.
- Explain the why behind pairing. This can be in a staff meeting. Keep it open and accept lots of q&a for team assurance.
- Accept volunteers. The entire team doesn’t need to be disrupted. Those that believe in the change will rise to the occasion. Forcing a change will never be sustainable. You will spend more management cycles enforcing an unpopular decision than being a multiplier for your team
- Start with a feature, not an entire product. Short pairing cycles will give you quick feedback and KPI’s on whether the team is willing and able to deliver with the new process. As more features are delivered, more individuals on the team can be paired.
- Select the appropriate tools. Collaborative IDE’s like Amazon Cloud9 or Visual Studio Code live sharing may speed up development and offer quick wins for the team.
- Document the ways of working on your team, so future pairs know the lay of the land. Especially in remote settings, written documentation and guidelines will bring new folks up to speed.
For more articles, tools and guidance from over 100 startup engineering leaders, subscribe to our weekly newsletter, Compass Weekly.