“Why pair programming? Putting two engineers together is going to cut my velocity in half!”
We hear it all the time and understand how counterintuitive pair programming can seem. After all, we’re asking our clients to allow us to team up two engineers for a majority of their day, tackling a single problem together. Shouldn’t they split and attack two different features?
The core of this objection is rooted in a fundamental truth: Good software engineers are scarce. And so, putting two of them together on a task certainly seems like a lot of waste, doubling the number of people needed to produce quality code.
Add to that, software development has traditionally been seen as a solitary activity, and both managers and practitioners are hesitant to adopt a different model. From an engineer’s perspective, they may feel that partnering with another engineer, especially someone who may be more junior, will slow them down.
To make matters worse, a quick Google search on pair programming returns articles that discuss the practice from two extreme points of view: Engineers and managers who love it or those who hate it. For those that hate it, I have to wonder if they’re doing it correctly.
In my 20 years of managing engineering teams, I’ve seen both. In every case, when I had an engineer come to me bemoaning the experience, it was — without exception — due to having no structure in pairing. I won’t discuss the myriad of pairing styles here, but suffice it to say that just putting two engineers side-by-side and expecting it to “just work” rarely delivers the benefits of pair programming.
Pairing, like any skill, requires intentional forethought into what outcomes you want to achieve, clarity on desired outcomes, and discipline. And, when done right, it offers many benefits to engineering teams and organizations alike.
The Benefits of Pair Programming
Many 66degrees clients come to us with a need to accelerate the delivery of mission-critical software products. Some will have internal product teams struggling to deliver, while others may not have dedicated teams at all.
Let’s look at the benefits using two scenarios and talk about how our styles of pair programming differ in each case.
Increases Code Quality and the Speed of Delivery
For clients without a dedicated team, our engineers pair with the outcome being better code quality, increased speed of delivery, and elegant, well-written code that’s easy to support once our engagement ends. (That’s achieved not only through pairing but by practicing test-driven development in parallel with pair programming). Enablement may not be as important, as our engineers are pairing with one another and are generally similarly skilled, senior practitioners.
That’s not to say, however, that even the most experienced engineering pairs don’t learn from one another.
When pairing, the organization gets the benefit of shorter feedback loops and greater adherence to code standards. Defects are caught much earlier in the software development life cycle, all but eliminating the need for formal code reviews and manual QA testing.
Enables Engineers to Upskill
What about clients who have existing development teams? How do they benefit from pair programming? All of the benefits above still apply, but there’s an additional benefit in the form of enablement.
Some of our clients may be new to a particular framework or technology. Pair programming with our engineers gives them the ability to deliver valuable solutions all while upskilling their team. We believe that the best way to learn is by doing — not by attending a seminar or workshop where retention is low, and the problems presented are too generic to be applicable to our client’s specific needs.
Enablement may also be needed in agile practices and principles, including pair programming and test-driven development. By being explicit in enablement outcomes, we can “dial in” on the development of specific, relevant skills and patterns that will not only help our clients get to market quickly but enable them to go fast forever.
Breaks Down Knowledge Silos
There’s another huge benefit in both of these scenarios — there is never a situation where a single person on the team carries all of the contexts for any given implementation. How many times have we been in a situation where our team’s velocity comes to a halt due to a team member’s absence?
When an engineer is on vacation, or exits a company and carries all of the contexts with them, your organization will pay an expensive premium as other members spend time getting up to speed. Pair programming can eliminate this risk altogether, resulting in code that’s much easier to maintain.
Improves Cost Efficiency
Finally, let’s address the economic benefits of pair programming.
No doubt, two engineers are more expensive than one, and these highly skilled practitioners are not low-cost. In a study conducted by Alistair Cockburn and Laurie Williams, the authors addressed the economic question by researching cost-per-defect and incremental time and cost spent as a result of pair programming.
The study found that the modest increase of 15 percent in development time as measured by lines of code/hour was drastically offset by code quality, reduced number of defects and resolution cost, lost productivity due to the accumulation of technical debt, and reduced expense in QA as quality shifted earlier in the SDLC.
Learn More About 66degrees’ Approach to Software Development
Clearly, pair programming can be justified on economic grounds alone, but the ancillary benefits shown above create a solid case for adopting the practice. If you’d like to learn more about how we approach software development at 66degrees with pair-programming, test-driven development, and more, connect with us today.
