A Pair is Better Than One

Pair Programming Delivers Better Code

Written by: Uzair Khan

Pair programming is an agile development technique where two programmers work together at one computer on the same piece of code. I first learned about pair programming in University but it wasn’t until I worked for an agile software development firm that I gained first hand knowledge of what it’s like to practice pairing all day.

Pair programming has always been a controversial agile development practice. I initially had doubts about pairing and like many people wondered: “Doesn’t pairing cause development to take twice as long?” However once I had the opportunity to complete a large project in a pure pair programming environment, I was hooked. I have since worked at various companies, some that pair and some that don’t. Having these experiences over the course of my career has allowed me to see both the positive and negative aspects of both pairing and non-pairing environments. To this day, I hold the opinion that pairing is the best way to develop software.

I joined Connected at the end of last year because I longed to be back in an environment where pairing was the norm. I’m thrilled to be at a company where one of the core values is “Pair it Forward.”

My friends, clients, and former colleagues have always asked me similar questions about pair programming over the years, so I decided to write a blog post to answer them. My goal is to address all the major concerns regarding the practice and explain why Connected has established pairing as a fundamental company value.

How does it work?

Quite simply, pair programming is where two programmers work together at one computer writing the same piece of code. The developer at the keyboard acts as the “driver” who writes the actual code, while the other developer acts as the “navigator” who guides the direction of the code, reviews the code as it is created and focuses on the larger strategic direction of the implementation.

Who uses Pair Programming?

This practice has been used over many decades by various teams in an informal manner, but more recently it gained widespread adoption in the 90s with the rise of Agile development practices such as Extreme Programming (XP), which uses pair programming as a fundamental part of its process.

Many development teams have incorporated pair programming as a methodology that they follow, while some practice it when they feel they need an extra set of eyes. Here at Connected, all of our projects are developed with a minimum of one pair of developers working in a pair programming environment.

Pairing at Connected

Pairing is so important at Connected that we have it as an actual company value. The benefits of pairing have been so apparent to the team at Connected, that many other non-technical members of the company have also established a culture of pairing. At Connected, you will often see designers pairing amongst each other or with engineers, and even sales reps with developers and designers. We feel that pairing has and will continue to be one of the reasons why we are known for building high quality amazing products for our clients.

Why You Should Do It

Here are some key reasons why you and your company should consider pair programming:

1. Increased Collaboration

Most developers have experienced working all day stuck on a problem, only to have a colleague quick glance at their work and offer some assistance almost immediately. Pair programming gives you a second set of eyes at all times. Pairing requires programmers to think out loud and articulate details and complexities of a problem being solved, which usually leads to highly creative and efficient technical solutions. Many developers have told me that their communication skills have greatly improved as a result of having to “program out loud” with their pair.

2. High quality solutions

Solutions created by a pair are almost always of very high quality, due to the fact that the navigator’s sole job is to focus on high level strategy and look for ways to optimize the solution. In addition, both programmers usually bring different experiences to the task and, as a result, usually generate a wider range of solutions to a given problem than a sole programmer would.

3. Constantly reviewed code is of higher quality

In a paired environment, the process of reviewing code becomes more effective because the pair already understands the context, whereas, in a traditional code review, the reviewer needs to spend extra time trying to understand it. With pair programming, there are already two sets of eyes on a piece of code, so a formal code review is not always needed. At Connected, we still do code reviews in most cases, to ensure all the merged code is of the highest quality.

At Connected, our pairs pair with other pairs!

4. Sharing knowledge

One of the biggest benefits that most developers who practice pair programming all agree upon is that pairing allows you to learn and absorb a large amount of knowledge in a small amount of time.

Junior developers usually learn a great deal from senior developers in such an environment. In addition, senior developers can also be exposed to new perspectives and learn innovative ways to solve problems from junior developers.

Whether learning a new language, platform, or design skill, the amount of knowledge shared in a paired environment cannot be achieved in such a small amount of time in a solo developer environment. When a developer is tasked in learning something new, they have to go through many tutorials and read many articles that could be taught directly and more efficiently by a paired developer instead.

No developer can be an expert in all development languages, platforms, or best practices; being able to pair amongst various team members with different backgrounds allow developers to learn a great deal from their peers and widen their experience. If a single developer is an expert in one area of a codebase, pairing them with another developer with little knowledge of that area, can spread that knowledge very quickly and avoid silos of knowledge within a team. Knowledge sharing is extremely important at Connected, since we work on new platforms and cutting edge technologies all the time.

5. Staying productive

We all have times during that day that we get distracted and lack focus, especially when working on a task alone. Sometimes procrastination sets in and we need someone else to hold us accountable. Pairing means both parties hold each other accountable to stay focused and productive. This is very crucial and important to us at Connected. We strive to be efficient and productive during a 9am-6pm workday. This means we leave our work at the office and rarely work overtime.

Pair programming gives you a second set of eyes at all times

Common Concerns

Most people think that having two developers working together will increase the cost of development as well as the delivery time. A naive look at the process would imply that the cost and time is double that of two solo developers. However, there have been many studies done to compare the cost between the two methods and an estimate of the actual overhead is only 15% relative to two individual developers. Another finding is that the resulting code has roughly 15% less bugs on average.

Experienced developers know that identifying bugs and resolving them early is drastically cheaper than any additional maintenance and bug fixing later on in the development process. This is the the main tradeoff in pair programming: a little bit of extra time overall for a large decrease in potential maintenance costs down the road. Having experienced both pairing and non-pairing environments, I have seen some of the nightmare maintenance/bug fixing periods in solo developer environments that sometimes add up to double the actual implementation costs.

Challenges

Pairing does come with its share of challenges. Pairing requires that individuals be open to working with anyone and of any skill level. It requires a level of maturity, patience, a certain amount of humbleness, and an environment where egos are thrown out the window.

Developers who are very experienced will need to slow down and explain things to their pair who may not be as familiar with the problem. Such experienced developers, although they may feel they can move faster, do need to keep in mind the overall benefits of pairing for both the team and the project and resist the urge to be a cowboy or a control freak.

Pairing can also be challenging for developers who are naturally introverted as they don’t have an innate sense of programming out loud. For such individuals, it can take a while for them to feel comfortable in such an environment.

I often hear many people say that developers work best when in their own corner, wired in with headphones and “in the zone.” Although this is a common environment in many organizations, I’ve seen firsthand that developers can achieve great things when they step out of their natural tendency to be alone and work in collaboration with others.

Final Thoughts

We love pair programming here at Connected and we feel it is the best way to develop software in a collaborative agile environment. If pairing is not the norm at your current workplace or on your current project, we encourage you to try it out and let us know how it works for you!

If you like this article, please favourite it and share it with your network.Stay connected by signing up for our mailing list here. Thanks for reading!

Uzair is an Engineering Manager at Connected, where he leads, mentors and manages our talented engineering team. He is passionate about software craftsmanship and agile development, building amazing world class teams, and consistently improving the way software is implemented and delivered. He values time with family and friends and loves movies, especially from the 80s — if you get him started on Back to the Future, he will recite to you every line in the movie.

Connected Lab is a product innovation and delivery firm. Our mission is to build better products. We are digital natives and have helped ship some of the most disruptive products of the last decade.