Advantages of pair programming in software development
Moving to pair programming is challenging. By “challenging” I mean in the way that people say, “We know this is a challenge, but how can you say you don’t like it if you don’t try it?” I’m picturing my mother with a plate of brussels sprouts.
This won’t be another “pros and cons of pair programming” piece. You can find those all over the internet. The journey to a successful pair programming experience isn’t just technical; it’s emotional and societal. There is much that isn’t said about the things that go through people’s minds as they make their way down this road. But that is part of the journey and it’s just as, if not more important than the technical impact or the business value.
What Has Gone Before
My first experiences with pair programming were at Hewlett Packard in 2001 - 2002 where we were experimenting with a locally customized form of Extreme Programming (XP). XP, for those who aren’t familiar, was more-or-less the spiritual predecessor of the modern Agile movement. Around that time, iterative processes had started to gain ground over waterfall models and there was a lot of excitement about a future where software engineering emphasized what is now known as the Agile Manifesto.
Pair programming predates XP if you dig deeper. Fred Brooks of “The Mythical Man-Month” fame reports using it in the 1950’s to “…produce 1500 lines of defect-free code; it ran correctly first try.” The concept is actually quite old, but the challenges of adoption and successful application remain the same.
At the turn of the century, pair programming as prescribed by XP was much the same as it is today, except that the “Driver / Navigator” model was the prevailing way of working. Laptops were non-existent in the workplace for developers and desktops with a single keyboard and mouse were the norm. You shared the keyboard and mouse back and forth, which led to a natural mentoring situation (and sometimes a long cold and flu season). It worked really well for the short time we employed it. At the time, I didn’t practice it long enough for it to leave a significant impression, but there were hints of a greater value.
Fear and Healthy Skepticism
What’s different about pairing and what you do now? As a software engineer, you might be used to coming to work, getting some coffee and some breakfast, checking the news and Reddit (or Slashdot, depending on how old you are) and then hitting a stand-up meeting. After that, you’re settling in to do some coding while listening to your favorite streaming service. What a great day, right? You get to do what you love to do and then perhaps head out to lunch with your coworkers or maybe to the gym. After that, it’s back to the coding. Later on, there’s a refinement meeting or a design session – or a short walk or a game of ping-pong – but generally, you’re on your own and you get to do things the way you like to. Sweet.
So, now there’s an announcement that your organization is moving to pair programming. The Skept-o-Meter is peaking – you’ve heard about this or maybe learned about it in college – it sounds like some dystopian version of what your current daily routine is. What does this mean for you? This industry is rife with introverts – are they intentionally trying to sabotage morale? What do I talk about with people I barely know and have nothing in common with? What if I have personal space issues and the idea of being so close to another human for six hours a day is like a living hell? What if I just don’t feel like dealing with another person one-on-one some days? It doesn’t help that the people who are asking you to embrace pair-programming aren’t typically the ones who have to live the day-to-day experience of it. There’s a bit of resentment underneath it all. It could be time to tune up the résumé.
I experienced many of these apprehensions. From the individual perspective, pair-programming is initially very disruptive and mentally exhausting. The societal and personal sacrifice aspects of it are the most difficult to overcome. It requires that you become at least marginally more social than you may already be. It also requires that you let go of a lot of personal freedoms. It’s one of those things that most people will react to at best with curiosity and at worst with real anxiety. You cannot sugar-coat pair-programming. You can try to tell people that it’s for the greater good, but they won’t really believe that until they experience it fully and form their own opinion. Healthy skepticism should be expected for the first phase of pair-programming adoption, as it would be for any significant shift.
Yet despite all of these very genuine concerns, the benefit would become clear; a few hours of close quarters with my colleagues, helping some of the junior folks to those “Ah-hah!” moments, cracking a really tough design problem, that feeling of shared accomplishment – all of these things would soon overshadow the initial mixed emotions.
The Pairing Experience at Sparta Systems
Pair-programming at Sparta has been very effective. Our team – the TrackWise R&D Team – was the second of the two product lines to adopt pairing. Each of the major product R&D teams adapted the practice to fit the teams’ norms. The Stratas team adopted a more canonical practice through their extensive engagement with ThoughtWorks. The TrackWise team opted for a style that was more in keeping with our established Agile practices and our highly valued camaraderie. The bottom line is that pairing can be adjusted quite easily to fit a wide variety of team dynamics.
One of the biggest pair-programming wins for the TrackWise team was in the mentoring of new team members. TrackWise 9.0 development saw a significant staff-up with a mix of junior and senior software engineers. In the past, one of biggest challenges facing us in this scenario was the complexity and volume of the TrackWise codebase.
Prior to the introduction of pairing, a fair estimate was that it would take a developer close to two years to become familiar enough to be productive independently. By pairing new engineers with seasoned engineers, this ramp-up time was decreased drastically – such that in the timeframe of the TrackWise 9.0 development cycle (14 months), the newer team members were nearly fully able to work independently. Naturally, thanks to the pairing model they did not have to work alone, and thus were directly contributing to their pair’s efforts after just a few months on the job.
Another big win for the TrackWise team was that as the mentoring effect took hold, the team’s velocity began to increase far beyond initial expectations. This was unexpected but it made sense in retrospect as the team’s confidence and skill level had grown with each successful sprint. There was willingness to take on additional stories as time went on and even when sprints looked like they were in jeopardy, the team would rally so as to prove they could succeed and get the satisfaction of closing out the additional work. The effect was contagious.
Pairing When It Makes Sense
One of the early decisions that was made was that the team wouldn’t treat pairing as an all-or-nothing endeavor. Pairing 100% of the time shouldn’t be necessary – for a lot of good reasons:
- Story on the rocks: Sometimes a story’s scope might have been underestimated or post kick-off design changes were necessary mid-sprint. The pair could split up and divide the work to parallelize the effort.
- Odd man out: When there was an odd number of developers (for whatever reason) that was an opportunity to get ahead by playing a spike or a technical story that would position the team better for the current or coming sprint.
- I need a break: Pairing fatigue is a reality. When there’s an opportunity (small story or spike / investigation / technical task), a developer could opt to take it on their own.
- Back from a sick day: No need to share the misery – take a break from pairing and work on something on your own.
Preserving Team Culture
One of the most significant takeaways from the first year or two of the pairing experience for the TrackWise team was that it was possible to preserve the important aspects of what made the team successful before pairing was introduced. The entire R&D organization can still be aligned as far as general best practices and processes, but the product teams don’t have to operate identically. This applies to Agile / Scrum as well as pair-programming. Pairing can enhance the strengths of the team without asking them to give up the things they value most.
To quote the Wikipedia entry, “Emergence is a phenomenon whereby larger entities arise through interactions among smaller or simpler entities such that the larger entities exhibit properties the smaller/simpler entities do not exhibit.” It’s almost like the old saying that the “whole can’t be greater than the sum of the parts”, except that it can.
My own personal experience with pair-programming is that it brings the best ideas to the surface and the interactions between pairing individuals can sometimes result in something different and better than either of them offered up to begin with. It’s also taught me the wisdom of knowing when to speak and when to listen. It seems that if you’re doing it correctly, your ego should be in the back seat and you should be listening and trying to help find the best path to a solution. A colleague once told me that “everything is a journey and a conversation.”
I’ve come to believe that collaboration in the form of pair-programming is just that.