Overview
A vast number of companies embrace pair programming as a way to increase programmer productivity (loosely defined as delivering “value” which can have many forms, but is generally interpreted as writing more code per day), but is it really that great? wondered why we should pair program and when is the right time to embrace it as a strategy.
Pair programming, as understand by the software community, came into popular culture as a facet of XP (extreme programming), a development framework that enforces practices that generally improve software quality and responsiveness. The idea is a new incarnation of the old adage: “two minds are better than one.”
Either way, the idea is right – two people have different histories, cultures, and experiences, so for those reasons they think about things in different ways. When two people work on a problem together they almost always come out with a better solution than a solo venture.
So how does this relate to programming?
The Positives
Pair Programming Does Reduce Bugs
The primary driver for pair programming is to increase quality and decrease bugs. When done well, it does that spectacularly. One study found that pairing reduced bugs in production by 15%!
Pairing Does Increase Code Quality
Many of the benefits of pair programming are not actually technical: they’re social. When working with a peer, it’s normal to feel encouraged to do one’s best, ensuring the coding is clean and avoiding any technical debt that they’ll “fix later.”
When pairing, one tends to do things just a little bit cleaner, making algorithms easier to read and naming variables more sensibly. A Software Team will actually write unit tests to 100% coverage! With two sets of eyes, the quality is always higher.
The Variables To Keep In Mind
Pair Programming Does Not Entirely Eliminate Bugs
As much as one would love for pairing to just eliminate all bugs, it’s just not the reality. Bugs still happen. There are generally a lot fewer of them, but perfect code would require perfect programmers.
Pair Programming Does Not Fix Poor Product Direction
Good projects need very strong product direction. And to be clear, the responsibility for this direction is on everyone, not just “product people.” It begins with asking questions and making informed decisions about work to be done. Then the team needs to thoroughly discuss the work, breaking it down as much as possible to understand the full scope. If this isn’t done properly, deadlines are missed, everyone is stressed, work that should take minutes take days… Pair programming can’t fix that. Nothing is more important than good product direction.
Pair Programming Needs To Be Done Right To Mean Anything
Pair programming is a tool meant to help make a difficult problem more digestible.
Pair programming, when done correctly, generally means one person is writing code and the other is directing the work. Directing in this case means providing feedback about best practices and constructive criticism. It also means researching those best practices when one doesn’t know them off the top of their head and taking the time to think deeply about possible edge cases and hangups relevant to the work at hand.
Pairs should communicate thoroughly, share all relevant information about their work, and swap duties as often as possible. It’s taxing to think about problems in both a creative and technical way, so it’s better to distribute that work. That’s one big reason that pair programming is such an effective tool.
When To Implement Pair Programming
Pair Program When There Is A Very Difficult Problem At Hand
If you have a problem that cannot reasonably be broken down into smaller parts, it should be met by multiple programmers.
An 8-point story should generally never exist in an organization if doing normal web work. Features can almost always be broken down into “front-end” and “back-end” stories. Whole-page mockups can be broken down into component parts. Design and QA phases can also be separated out into their own stories. But a really tough problem is just a really tough problem.
Trying to add a new feature to a language is a really tough problem. Trying to figure out how to reduce the latency on database calls is a really tough problem. These are examples of problems that require both creative and technical thinking.
Pair Program When Two Programmers Are At Completely Different Skill Levels
Pair programming is a remarkably good way to teach junior programmers. Getting to participate live while a more senior programmer talks about how and why they’re doing something is ab invaluable experience. So is writing code while a more senior programmer coerces better practices on the fly.
Pair Program When Two Programmers Have Completely Different Skill Sets
Having two programmers with complementary skill sets can be very rewarding for both the programmers and the codebase. Pairing programmers who generally only work front-end or back-end can get an end-to-end feature out the door, or a Postgres expert pairing with a Scala expert to make a database call more efficient.
When two programmers work together live, they absorb a lot of knowledge about each other’s domain and ensure there’s no aspect of the project that’s neglected.
Pair Program When Both Programmers Are New To A Language/Framework
Sometimes a situation arises where nobody is an expert. This is an excellent learning and growth opportunity!
A project will end up with two programmers working through a difficult problem and contributing their individual skills to build a better product, helping each other learn, and with a redundancy in the skill growth of programmers. This is important because the skills in within an organization should never be concentrated in one person. Having programmers pair on new languages and/or frameworks ensures that there are a minimum of two people who can work on this in the future.
Closing Thoughts
The best way to approach pairing is to partner two programmers and have them share a computer. Make them work together to architect, code, and then test their codes in a genuine sense of a partnership. While the ideal setup would include two programmers who are equally skilled (expert – expert or novice – novice), you can also use pair programming for training and educational purposes (expert – novice).
The pair should be able to decide how to split the work, and it is advisable that they should switch roles often.
