Pair programming has been around for many years now, with people having varying opinions about it. While it was born as a practice for a colocated pair of developers, how does it work nowadays when many people are working remotely from diverse time zones? Is this the final blow for the pair programming practice?
Pair programming was first described in the late ‘90s in the Extreme Programming Explained book from Kent Beck as the agile software development technique in which two developers team together on one computer to design, code, and test user stories.
Even if the term was first coined during those years, the practice is well older than this. As per Martin Flower’s blog, “Jean Bartik was one of the ENIAC women considered by many to be one of the very first programmers. She took on the task of programming […] and there were no role models or books to tell them how to do this, and they decided that it would be a good idea to work in a pair.” This was 1945.
Over the years, and over quite a few programming books, the community came about with different styles of pair programming:
- Driver and navigator, where the driver is at the keyboard and the navigator observes, reviews the code as it is being written, gives directions, and shares thoughts from a higher focal point so as to keep the big picture in mind
- Ping pong, where the ping developer serves with a failing test and the pong developer responds with the implementation to make it pass (and vice versa), while at each round refactoring the code together (if it sounds like test-driven development that’s because it is)
- Strong-style pairing, similar to driver and navigator, with the additional imbalance of experience between those two actors; this sees the experienced person mostly staying in the navigator role to guide the novice
The way the above styles function easily highlights the benefits of pair programming, e.g.:
- Fewer coding mistakes and oversights, as the pair is essentially a constant code reviewer, reviewing the code immediately as it is being written rather than when the pull request gets submitted; this prevents wrong initial decisions that affect the rest of the work
- Increased code readability, as the pair naturally tends to write more maintainable code
- Knowledge-sharing and constant knowledge transfer, not just about the task at hand (anyone heard about the bus-factor?)
- Team collaboration and coordination
- Increased resiliency, as the environment will not depend on a single person for repairs if something breaks
Therefore, if programming was born as a pair’s activity and it brings many benefits, you might rightly ask yourself, when did evolve from pair programming and choose to prevalently go solo? Might this be due to the advent of the personal computer? (At the age of ENIAC, computers were more like the size of a fridge, so I don’t believe they were “personal”).
Even if multiple empirical studies reported increased quality all of the time with no statistically significant cost overhead or increased quality and compressed schedules, the biggest enemy of this practice remains the apparent productivity loss. In fact, on the surface it seems obvious to think that about 50% of productivity is lost when two developers are working on a task that can be performed by just one of them.
If we add to the thinking above that some people work better alone, many of us work from home, and teams might be spread across multiple time zones, pair programming adoption fades like the clothes from the ’80s that looked fantastic at the time, but are definitely a no-go now.
I work on the Data Operations Team at LiveRamp. We have built a platform (Data Operation Platform – DOP) for building, deploying, and executing cloud-agnostic data applications for managing data movement throughout LiveRamp and customer data silos. DOP is built atop open-source functionality provided by Google’s DataFusion (CDAP), elastic search, Kubernetes, Spark, and various other big data tools.
My team is made up of six LiveRampers: two working from the UK, one working from France, one in Italy, one in Atlanta, and our team manager in Seattle. Together we cover two continents and five different countries. We have not had a chance to meet face-to-face yet, as most of us were hired remotely and have worked from home since the start of the pandemic.
Does the scenario above look like a good fit for pair programming?
Yes, it does. Pair programming not only worked for us by improving our productivity and knowledge, it helped us remain sane when the office and the world around us were forced to lock their gates.
Initially, we adopted pair programming as part of our temporary move to kanban. There was so much unknown in every task that deciding to have two people working on each of them was a no-brainer. We even tried making an all hands/mob programming on some of the most challenging and time-constrained tasks.
We progressively adapted our pairing style to our needs as we realized that on top of working from different time zones, we had different working patterns and personal needs. We could not pair for the entire eight hour workday (should we have, even if we could?), but rather, we initiated the task together and then paired at different time windows during the day, for example:
- When we were both online we paired
- When only one of us was available, we progressed the task independently until the other was available or the day was over; in the latter case, we sent a chat with a short handover to the pair (e.g. Francisco works individually from 16:00 to 19:00, and before wrapping up his day, he sends a short summary of what he has done to Clara so she can pick up where Francisco left off.)
This way of pairing forced us to keep our code clean and well documented, to write about our intentions, and to frequently summarize what we had done and what we were planning to do next. It forced us to think over and over about the task at hand while explaining/discussing it with someone else, making it crystal clear in our minds (the protégé effect to the square!).
Time-wise, we were pairing for four hours a day max, but the task was being progressed for 14 hours a day; meanwhile, we were grabbing the entire set of benefits of pair programming plus extras:
- Overall increase of per-developer velocity (see Strengthening the Case for Pair Programming by Laurie Williams(PDF) for another experiment on this)
- Knowledge-sharing, which was like working on the issue for 14 hours a day; each developer of the pair was fluent about the task, its status, the issues faced, plus all the reasoning behind the design choices
- Keeping each other on track (yes, even after a big pizza lunch!)
- Seeing the task progressing even when picking up kids from school or attending a doctor appointment
- We came to know each other better, rely on each other, help each other, provide a safety net, and even have fun (we now know how to greet in Italian, French, English, Sicilian, and more to come)
- We felt like part of a team
- Everyone released the frustration of otherwise being stuck on a critical issue on their own, at home, alone
Last but not least, it helped to complete tasks more consistently and in a timely manner, reducing the cognitive load associated with having too many streams of work being looked at the same time.
Finally, while refining our pairing practice, we gathered a few tips/tools that made our collaboration smoother:
- Use video if you can: people communicate a lot through gestures and facial expressions, so it’s nice to see the shared screen and your pairing partner’s video at the same time (Zoom to the rescue)
- Remove the tech barrier and connect in seconds: Slack Huddle allowed us to jump on calls immediately; also Huddle’s mark feature helped quickly point/draw on the shared screen
- Planning and designing: both Miro and Slack Huddle were our collaborative online visualization tools, helping us reproduce the experience of sketching out things on paper or a whiteboard (see some of our art below!). We used Swimlane.io to cooperate and share our sequence diagrams easily
- Audio experience: If you can’t get away from the noise, the “push to speak” functionality can also help; to avoid distractions on your side, noise-cancelling headphones are your friend
- Swap the pair: do this potentially at every task to enrich the team experience
 |
 |
 |
|---|
This has been our experience for the past nine months—now it’s your turn. Has pair programming been good for you? Please share your experience, as we are always interested in improving our team practice.