Shared Code Ownership

How many people on your team have to get hit by a bus (or go on a sabbatical) before your team is unable to function? The so-called bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members.

When your team consists of solo engineers, you end up with knowledge silos. Parts of the codebase are owned by specific individuals, and no one else knows how those modules work; in fact, other people on the team are afraid to make any changes. The owner becomes a bottleneck for the team, and new features can only be developed if that person is available. If that person becomes unavailable, the progress grinds to a halt.

XP practitioners forge collective code ownership. Every engineer on the team can work on every part of the codebase, whatever is the top priority at any given time. And since the code is collectively owned, everyone holds everyone else accountable for its quality.

Productivity vs. Quality

The first question most people ask is "So two engineers spend double the time to get the same amount of work done?" or "Can't we achieve a lot more by parallelizing work tracks, having everyone work on their own respective task?"

These questions are perfectly reasonable. On the surface, it appears that pair programming cuts the volume of work in half. However, underlying the question is an assumption that there's no productivity difference between solo engineers and paired engineers. But that assumption is demonstrably false—just ask anyone who's ever paired.

Just like it is a fallacy to believe that increasing time spent on quality and automated tests will delay the successful delivery of software, so is the idea that having two engineers work together on the same problem as opposed to working independently is slowing down the overall development progress

Writing production code only takes up a tiny fraction of the full software development lifecycle. Countless surveys and studies have shown that teams spend a lion’s share of their time on anything but typing code. In a study by Carnegie Mellon University, University of Auckland, and Pivotal (VMware), teams usually spend most of their time on software development wastes instead.

Teams often spend a major part of their time troubleshooting and fixing bugs that could have been prevented by spending more time on quality during development. Teams are adamant about the need for peer reviews using pull requests, but often underestimate the power of direct feedback through human interaction. Pull requests lead to context switching, waiting, and multitasking. On teams that don't pair, developers spend a good portion of their time reading pull-requested code and writing comments. Then the original author of that code has to respond to those comments, revise their code, and resubmit it. The extra overhead of code review and code revision can easily take up ~50% of a team's working hours, so by substituting pairing for code review we lose nothing. In fact, we save time, because the real-time code review provided by pairing is more efficient than typing comments back and forth on Github. Handovers within the team can lead to building erroneous, overcomplicated implementations, building the wrong feature, and performing rework.

Most, if not all of these wastes can be mitigated by applying pair programming. Pair programming actually increases velocity when taking into consideration the entire software development lifecycle. While writing production code might take longer, that only takes up a fraction of the time of the development team anyway. Waiting for reviews, bug fixing, context switching, rework, being blocked by the unavailability of people with the right knowledge or skills, and dealing with knowledge loss when those people leave the team, all take up considerably more time for the development team than typing production code. Pair programming helps to prevent these wastes, resulting in a net increase in velocity.

Pairing Isn't Easy

To achieve the level of effectiveness we expect from pairing, each person needs to value others' perspectives as much as their own. Not everyone is willing to develop the empathy and relationship skills required to collaborate at this level. Pairing also exposes intellectual insecurities. To pair, you have to overcome your own ego – you have to be willing to make mistakes in front of your pair. Some engineers are terrified of this prospect, and would rather quit than face their fears.

This is why pair programming can be exhausting. At KOR, we don't force people to pair 24/7. Engineers have the liberty to pair when they see fit, without being judged on how they spend their time. KOR gives engineers the freedom to experiment and experience the benefits of pair programming. As a result, the team has grown into a rhythm in which pair programming has become a central practice we couldn't live without.