Pair programming is the ‘buddy system’ of development strategies. Two developers buddy up, sit together, and work on the same piece of code — one writes and the other reviews, switching roles periodically. That means two eyes are constantly on the code, communicating solutions, sharing skills/training/tricks, and so on. It’s a tidy answer for instant code review, but as with any non-robot solution, there are inconsistencies based on the developer and situational specifics.
Keep Two Eyes on the Code at All Times
With two eyes on the code, your programming is essentially preventative in nature. This supports a ‘many eyes on the code’ approach, giving partners a greater ability to check each other, come up with workarounds, and build code with high quality and clear articulation. Accountability to a partner, on its own, is a driving force in code quality.
Communication is a constant source of strife for businesses, but pair programming basically takes the developer-to-developer communication issue off your hands. Best case scenario, you constantly switch pair programming partners, giving everyone on a team a chance to collaborate. Developers who enjoy working socially will welcome the change from working alone in a cubicle, and it’s a win-win for companies. With heightened communication and collaborative efforts, the resulting code is far more efficient than that of a solo developer.
One of main appeals for pair programming is the ability to train developers who are new to the company tools, or when employees need to learn a new framework, pattern, or programming language. Pairing is a quick, effective way to familiarize developers with new code and share best development techniques with one another. Pivotal Labs enjoys a great deal of success with use of pair programming. One of their engineers, Amit Gupta, says:
“I learned as much in two months of full time pairing at Pivotal Labs as I did in the two years of my master’s degree. When I pair, I get to be the student and the teacher a hundred times over in a single day. I am given the opportunity to learn on every scale, from a lengthy debate over integration testing vs. mocking to a little nod when my pair uses a keystroke I didn’t know.”
How’s that for continuous learning?
It’s impossible to ignore a reviewer who is sitting right next to you, but it’s easy to pass over shoddy work alone, under the assumption a code review will fix any/all bugs. Each pair must understand the code and the implications right then and there with the aid of immediate communication and accountability. Programming out loud is instant code review, and it prevents technical debt in the project’s future.
Traditional Code Review
The alternative to pair programming would be a traditional code review, where a variety of different strategies look over the code for errors and efficiency before it gets a final stamp of approval. Sometimes it’s a team lead doing this or sometimes an entire team, but the one thing code reviews all have in common is that the reviewing is done after the fact. Whether it’s every day, once a week, or so on, the risk for expensive errors is higher.
Code reviews, when well-executed, are very powerful enforcers of consistency, ownership, and bug-free code. The Linus Law that states, “Given enough eyeballs, all bugs are shallow”, is a nod to getting as many eyes on the code as possible. That may be the best weapon against buggy code, but not always the most time efficient option. Rather, some form of pair programming and traditional code review should coexist to give teams the best of collaboration and review.
Speed of pair programming vs. traditional code review is still a gray area. Plenty of managers believe that pairing developers cuts productivity in half, but that’s a short-sighted evaluation. Consider the time saved in repairing technical debt, arranging code reviews, and coordinating collaboration efforts with paired programming. The real value of paired programming is in what it saves you in effort down the road.
Empirical studies have shown paired programming overhead is around 15% greater than individual efforts, but again — that doesn’t take into account long-term benefits. Some would say that’s entirely false, and that pair programming is actually a faster method because pairs are more resilient to interruptions, and come up with solutions faster. There’s also time saved doing lengthy code reviews if the immediate review is fastidious. Instead, the code is written quicker and doesn’t need revisiting. One thing that’s fairly certain for speed of pair programming: the momentum of the learning progress is vastly superior to what most training methods could even hope to achieve.
The success of pair programming is largely dependent on developer engagement. If one person is in the clouds while the other works scrupulously, the benefit is negated.
You also can’t force people upon one another. Remember, you’re dealing with human beings — humans with varied emotions, relationships, working styles, and hygiene practices. Even for two programmers who get along very well, 8 hours with someone can be exhausting.
Skill level needs to be carefully examined when pairing people. If you pair two developers with low skill, you get subpar code. Pair two people with very different skill levels, and it’s likely only the lower skilled developer is learning while the more experienced developer is teaching without having their code reviewed. To gain productivity from pair programming, you need two people with similar skill levels who have something to learn and improve upon as a result of collaboration.
Paired programming done well makes for high quality code, a boost in team morale, and fast-track training methods. Incorporating some pair programming into your development strategy is a good idea, but it’s not the only way to go about code review or collaboration. Rather than looking at paired programming as an alternative to traditional code review, use paired programming as an addition in order to accomplish communication and training goals. Code review and programming pairing will both benefit the quality of code — just don’t force smelly people to sit together for a full eight hours a day.