Others
Pair Programming: Benefits, Tips & Advice for Making it Work
Jan
Here’s a great article from SitePoint
Pair Programming — a pair that’s greater than the sum of its parts. You may have heard about pair programming and wondered whether it was worth trying in your workplace. On the surface it sounds simple, but two developers sitting together are not all that it takes to achieve productive pairing.
Logistical and personal hurdles such as scheduling, tool choices, and distractions can stop you from getting the most out of pairing. But the potential advantages can make it worth the trouble of recognizing and surmounting these challenges.
Why Pair?
How could it be more productive to take two programmers who were previously working on separate projects and have them work together on a single project? Won’t everything take twice as long? To an outsider the idea of pairing may sound counterproductive at first, but the advantages become apparent when you start to think about why we code and what we’re trying to accomplish.
Programming is not about churning out the most lines of code in the shortest amount of time, or even delivering the most features within increasingly tight deadlines. You can have engineers working around the clock pushing new features into production, but how productive are they really if those features are cranked out by individuals working in isolation according to their own unique understanding of the overall architecture? The resulting code is likely to be riddled with technical debt such as hidden bugs, performance issues, idiosyncratic syntax, and inefficient designs that may not use resources efficiently and may make it that much more difficult and time consuming to modify the code when one of those flaws surfaces.
You need your code to be meaningful and well written so that it works together seamlessly and can be modified easily. You need it to encapsulate the desired functionality so that your end product behaves properly and performs as expected. You need it to be resilient so it can withstand organizational changes that are a natural part of working together, as well as environmental changes and new customer expectations that may make today’s workable solution obsolete without much warning.
In order to make that possible, developers need to be able to agree about fundamental requirements clearly, get up to speed quickly with whatever new or established technologies may be required, and focus without interruption to test out creative solutions and develop a product that’s worth putting in front of the customer.
These are the real-world challenges that pair programming helps to address. When two developers work together in a pair, the quality of the code they produce improves along with their shared understanding of how it works. This makes it easier for the next person who reads the code to pick it up and modify it when necessary, and it reduces the danger that the only person on the team who knows how part of the code works may win the lottery and leave the team, taking that precious knowledge with them.
The time cost in mythical work hours is nowhere near the 50% that may seem intuitive if you tried to to equate the intricate art of coding with repetitive assembly line work. Some empirical studies have concluded that pair programming might result in about a 15% increase in the time it takes two programmers to accomplish the same tasks had they been working alone, but the resulting code will also be of much higher quality, with about 15% fewer observable defects to fix. Combine this with the shared ownership, deeper engagement, and faster problem solving that comes from having more than one mind engaged in solving a problem, and it’s clear why pair programming is a popular approach.
What Exactly is Pairing?
So what does it take for two developers working together to achieve the productivity and quality improvements that come from pairing? It’s mostly a matter of learning how to work collaboratively, which is not necessarily the way most of us learned to code.
By definition, pair programming doesn’t start until you have two people working together on one computer. But how does that work in practice?
Two People …
The fundamental element of pair programming is working together with your pair. When a task is accepted, it needs to be shared between both of the people working on it, and they both need to be fully engaged in the task while they’re pairing on it. That means that they both need to understand the requirements the same way, and work together to come to a shared understanding of how they want to go about meeting them.
Pairing helps people get better at verbalizing their ideas and expectations. The implicit understanding you have in your head when you’re working alone needs to be communicated so both you and your pair know you’re on the same page. Getting as explicit as possible about the work and the approach up front will help make the pairing experience much more agreeable. Pairing involves a lot of talking, as that’s the best way to keep two minds actively engaged in the problem at the same time.
For this reason, pairing is often associated with agile story writing, in which requirements for a feature are defined in consistent, plain language that can be understood equally well by Product and Engineering people with little room for ambiguity. Often pairs will ask for stories to be spelled out in Gherkin, which is a way of using common, non-technical phrases that are easy to translate into automated tests, so the pair can verify and demonstrate that each feature works as expected.
Writing in Gherkin means taking a feature and breaking it down into a simple story about a customer who wants something that this feature will deliver:
As <a customer of the product>
I want <something desirable>
So that <I can achieve a specific goal>
Then all the acceptance criteria are written out in a consistent syntax, defining the anticipated permutations and scenarios associated with that story:
Given <a customer in a particular state>
When <something specific happens>
Then <there is a specific outcome>
Given <a customer in a particular state>
When <something different happens>
Then <there is a different specific outcome>
etc.
Of course, it’s not mandatory to use this exact phrasing, but if the requirements of a feature can’t be expressed in this minimalist way, it’s possible that the expectations are ambiguous. That’s a potential red flag that’s easier for a pair of programmers to spot when they start to discuss what’s needed.
As soon as a pair accepts a story to work on, they should be able to define how they will know they are done and how they’re going to prove it. From there, they can start to figure out together how best to approach the job.
In fact, the pair working on a feature should know enough up front that they could start by writing an automated test based on the first acceptance criterion before writing any code, making sure the new test fails, and then writing just enough code to make that test pass before refactoring and then starting on the next acceptance criterion. This approach is known as behavior-driven development, and while it’s not part of the definition of pair programming, it harmonizes beautifully, along with test-driven development.
The post Pair Programming: Benefits, Tips & Advice for Making it Work appeared first on SitePoint.