Pair programming is a method of writing software where two programmers work alongside each other sharing a single workstation (one screen, keyboard and mouse). The “driver” uses the keyboard and mouse and writes the code. The “navigator” looks out for mistakes and monitors the work as it progresses.
It’s important for both programmers to work together as a unit to make sure they get the best out of the session.
The driver writes code and talks through each step as the code is being written. The driver also makes sure that his partner stays focused and engaged.
It’s the job of the navigator to look out for any errors, making sure that you’re both on track and calling a halt if necessary to rethink where you are, where you want to get to and how to get there.
The programmers are expected to swap roles at regular intervals, preferably every 15-30 minutes to maintain optimum levels of energy and concentration . Whether a driver or a navigator it is essential that both programmers must be actively engaged with the task, otherwise no benefit will be realized.
Pair programming is also commonly called “pairing”, “programming in pairs”, “paired programming” and “programming out loud”.
How Pair Programming Works
- Two programmers just sit side by side in front of the monitor, sliding the key board and mouse back and forth between them. Both programmers need to be concentrating on the code being written.
- Pair programming is also sometimes called “programming out loud” and the driver is expected to keep up a running commentary while writing the code.
- As much as anything, pair programming is a social skill that takes time to learn, so don’t expect people to be good at it from the start. It will help a lot if there is someone on the team with experience who can show everyone how it works and what it should feel like.
- Pair programming is a cooperative way of working that requires give and take from both programmers. This may feel awkward at first and can take a bit of time to get used to.
- Pair programming is not mentoring, it’s two people working together as equals regardless of seniority or status.
The Top 10 Benefits of Pair Programming
There are several benefits of pair programming that make it an effective method to consider as part of your software development strategy:
- Increased code quality: “programming out loud” leads to clearer understanding of the coding tasks, which leads to clearer planning, better code and reduces the risk of errors.
- Fewer coding mistakes. Because there is another programmer looking over your work, it results in better code. In fact, one study shows that it results in 15% fewer bugs than code written by solo programmers.
- Two heads are better than one. If you come across an issue, then there are two programmers available to look into a solution so the problem can get fixed faster.
- Improved tolerance to interruptions: the navigator can attend to any external interruptions, allowing the driver to remain focused on the task at hand. This also helps to reduce coding mistakes due to external distractions and helps maintain productivity.
- Pair programming is beneficial for achieving correctness on highly complex programming tasks.
- By cooperating, programmers may complete tasks and attain goals that would be difficult or impossible if they worked individually
- Increased knowledge transfer. Pair programming can help developers to learn from one another, and spread best practices and better techniques used by advanced programmers around the team. And of course, less experienced team members can be paired with and learn from more experienced colleagues.
- Work continuity. With pair programming, there are at least two people that know how the new software works. This means that if one of the pair leaves the company, overall project progress will not be affected.
- Improves communication and collaboration. Pair programming can help to develops each individual member of staff’s interpersonal and communication skills, while collaborating on a single project helps your team to appreciate the value of teamwork.
- According to one study, pair programming may also save time on simpler tasks.
7 Steps to Prepare for Pair Programming
- Plan enough time for the session. The amount of time needed can vary, but anything shorter than 2 hours will probably feel restricted. Start with 1.5 to 2 hour sessions and build up from there to see what works for you. Many experienced developers report that a good session length is around half a day.
- Get in the correct frame of mind. Make sure that both you and your partner are happy to go ahead with the session. Perhaps one of you is feeling unwell or has some personal issues to deal with. Or maybe one of you just had a particularly heavy session the night before! In which case it’s probably better to reschedule to a time when you are both at 100% focus and productivity.
- Get comfortable. Choose a space that’s comfortable for both of you, ideally not too loud. You should both be able to comfortably read the screen contents as work progresses.
- Make a plan. before you start coding, talk about what you want to achieve during the session. Writing down objectives on post-it notes is a good way to plan your session.
- Establish a rhythm. As well as swapping roles frequently, commit code changes frequently to keep things flowing. Writing a commit message helps express your progress in words. It’s also a chance to reflect upon whether you are moving in the right direction.
- Celebrate each stage of progress. Recognizing each small success (this can be as small as finishing one small task) will help keep you motivated, focused and on track.
- Take regular breaks and don’t be afraid to take one whenever you need it. Planning a break after each completed task is fine, but if you feel worked up or stressed, don’t feel you have to wait until the next task has been completed before taking a timeout.
Does Pair Programming Cost More?
One of the main perceived downsides of pair programming is that it costs more to write code this way. After all, we are employing two programmers to write code instead of one, and some studies suggest that there will be an additional 15% cost overhead when using pair programming.
However, it is expected that this overhead is mitigated by gains in code quality with less rework and fewer issues, which are often significantly more costly to fix the later in the development cycle they appear.
Pair Programming vs. Code Reviews
Code reviews, or code inspections, involve another programmer (or programmers) looking at your code to identify improvements or find defects. This has been shown to accelerate and streamline the process of software development.
In days gone by, this may have involved a group of people sitting together around a table in a darkened room, proof-reading dot-matrix print-outs of computer code with a red pen until they fell asleep from boredom or gave up the will to live.
But these days, long formal code review processes aren’t typically necessary unless the software under development is mission critical. For example, as in avionics where a failure could result in the death of a large number of people.
For non-mission critical software development, a number of more lightweight code review processes have developed. In pair programming pair programming the “code review” is built into the process. Two developers work on the same code together and check each other’s work as they go.
This approach is compatible with streamlined Agile workflows and iterative production cycles and helps to deliver the time and money savings that are so crucial in the modern business of software development.
There are a couple of disadvantages. Firstly, authors (and co-authors) tend to be too close to their own work, and so there may be less objectivity than with other methods. And secondly, pair programming can also use more resources, in terms of time and personnel, than other methods.
What are the Downsides of Pair Programming?
Pair programming can be slow and frustrating. It can be extremely annoying and frustrating to have to explain and agree on every single thing you are doing, and having long debates on the simplest of things like naming a variable and other basic design decisions.
Pair programming is far easier when developers have a similar foundation and share an understanding of the basic concepts. Then they can focus on finding a better solution to the problem instead of wasting time on debates on mundane questions of style and semantics.
Also, encourage regular technical meetings, define standards and use occasional format code reviews to share knowledge of best practices and bring the whole team to the same level of understanding.
Pair programming can be very tiring. Spending the whole day with another person debating, justifying and trying to agree on everything can be intense and very tiring. In some cases, developers can become exhausted by the end of the day, and feel that they have had no time for themselves.
So make sure you have regular breaks and also schedule some down time where the developers can spend some “alone” time if necessary.
Pair programming can stifle creativity Sometimes you need space for creative thinking and to innovate. It can take time for new ideas to form and the creative process can be impaired when you are under time pressure or there is a person sitting next to you waiting for you to tell them your big idea.
It’s important to allow team members to work on a task alone if they need to. After working alone for a short period of time, the ideas can then be shared with the rest of the team, perhaps choosing a pair to expand and finish the work.
Inexperienced developers do not always benefit from pairing. Pair programming can be a great way to mentor inexperienced developers, but new developers also need some time alone to do their own research and make their own mistakes. Developers learn by doing it and they need some space to do things at their own speed.
Suggest starting a task as a pair, have the experienced developer give some high-level directions and suggestions, and then let the inexperienced developer do the task on their own.
Make sure that someone is on hand if they get stuck, and have the experienced developer review the work once completed so that improvements can be suggested and different approaches can be compared.
Pair Programming – Is it Right For You?
With pair programming, two software developers work on one computer, collaborating on the same design, algorithm, code, or test, which can be challenging for individuals or teams not used to working in this way.
Since the method was first introduced almost 20 years ago, some organizations have adopted paired programming completely while others only use it in certain situations and types of development.
Many other organizations still fear the practice will double their development costs, but studies do not show this to be the case, with reported benefits outweighing any increase in costs.
While the quality achieved by two people working on the same task is superior to when done by a single person, it is also important that space for individual creativity and learning is provided. Paired developers should share the same goals and work as a team.
In summary, pair programming is an important and useful technique for developing higher quality code quicker while also reducing risk and spreading knowledge in an organization.