What is pair programming in software engineering? 🚀

My initial introduction to eXtreme Programming (XP) concepts dates all the way back 2001 when I was working on a project in Ireland and the development team I was on adopted some of the XP concepts — pair and mob programming being two important strategies that proved to be quite helpful.

In 2006 I signed the Agile Manifesto as an independent signatory.

From time-to-time throughout my career I’ve had the pleasure to work on various agile teams that followed the Agile Methodology sometimes closely, and sometime loosely.

During the summer of 2019, I had the opportunity to work on a ten-week engagement with a group of excellent software engineers in Colorado and on that Agile project we followed agile practices closely and, in addition, we incorporated eXtreme Programming practices as well.

Several strategies of software development that I had the pleasure of experiencing again on this engagement included the incorporation of pair programming (pairing), pair rotation, and mob programming (also known as mobbing or mob programming) — these are software engineering strategies that come out of eXtreme Programming (XP), which is a subset of the Agile Software Development, and is a software development methodology popularized by Kent Beck circa 1996.

The result of developing software with Agile project management practices and XP practices resulted in an impressive acceleration with respect to the amount of work being delivered in a relatively short period of time.

This method of working also led to a more cohesive team, one where information flowed freely amongst the group, and one with a better view of the overall mission.

So what is pair programming in software engineering? We’ll learn more about pairing in this case study, along with mob programming, which is another useful eXtreme Programming concept.

Project Summary, Cloud Migration Details, and eXtreme Programming

This project was technically challenging work, where we took an existing Java-based monolithic web application running on the open-source Apache Tomcat servlet container and transformed it into an application that adhered to a microservices architecture and was deployed in Kubernetes running on AWS.

Another deliverable on this assignment was to work with the client using Agile approaches to software development including eXtreme Programming methodologies.

Finally, we also set up continuous integration and incorporated united testing strategies for the applications we were developing on in this project.

What Is Pair Programming In Agile Software Development?

Pair programming is an XP practice, which is a subset of the Agile software development methodology, where two developers work together on the same task.

In the past this would have been done on the same computer however in recent time there are tools available that facilitate collaborative coding efforts performed remotely, for example see JetBrains Code With Me and Microsoft Visual Studio Live Share, both of which facilitate collaborative coding and pairing.

In typical pairing, one developer drives the development and actually writes the code, while the other developer shadows the developer and provides feedback and guidance, reviews the code, and suggests improvements.

The two developers switch roles frequently to ensure that both are engaged and contributing equally to the work.

The use of two keyboards and two mice on one computer is typical in this style of software development.

Collaborative development is intended to improve the quality of the code, increase productivity, and facilitate knowledge sharing and collaboration between team members.

Pairing can help catch errors and bugs early in the development process and improve the design of the codebase.

Pairing also provides an opportunity for developers to share their knowledge, skills, and perspectives, which can lead to a more robust and efficient development process.

Pairing can also have benefits beyond the technical aspects of software development.

Pairing can help build trust and rapport between team members, reduce communication barriers, and promote a culture of collaboration and continuous learning.

Pairing can also help newer or less experienced team members learn from more experienced developers, which can improve their skills and confidence.

Finally, pairing can help keep developers focused on the task at hand and completing the effort without deviating into unnecessary development or writing unnecessary code.

Overall, pairing is a useful practice in Agile software development that can improve code quality, productivity, and collaboration among team members.

Benefits of eXtreme Programming from the software developer’s perspective

eXtreme Programming (XP) is a software development methodology that focuses on enhancing the quality of software and the responsiveness to changing customer requirements.

From the perspective of a software developer, projects that incorporate eXtreme Programming deliver several benefits:

Continuous Feedback

With frequent releases and continuous integration, software developers receive regular and timely feedback about their work.

This helps the software developers catch issues early on and adjust their code as needed.

Reduced Documentation

XP emphasizes working software over comprehensive documentation.

While documentation is important to some extent, XP ensures that developers aren’t bogged down with excessive paperwork, allowing them to focus on coding.

Pair Programming

Pair programming (pairing) is one of my favorite modes of working when it comes to developing software.

Pairing is where two developers work on the same task together.

Pair programming facilitates knowledge sharing, improved code quality, and continuous peer review.

Pairing often leads to fewer bugs and promotes a deeper understanding of the codebase.

Emphasis on Testing

XP promotes Test-Driven Development (TDD), where tests are written before the actual code — this is also referred to as test-first development.

Test-driven development ensures that code is appropriately tested, and this results in fewer bugs and ultimately more stable software.

TDD also gives developers confidence when making changes, as they can rely on tests in a comprehensive test suite to catch issues that may appear when changes are made.

Sustainable Pace

XP advocates for a work pace that developers can maintain indefinitely, thereby lowering the chances of burnout.

Overtime is seen as a sign that something is wrong, and the XP methodology promotes a healthy work-life balance.

Embracing Changes

Developers don’t need to fear changes in requirements, as XP’s iterative nature means changes are expected and managed effectively.

This can be liberating for developers who, in other methodologies, might see changes as disruptions.

Clear and Simple Design

XP encourages developers to focus on the simplest solution that works.

By avoiding premature optimization and over-engineering, developers can produce clean and maintainable code.

Collective Ownership

All code is owned collectively by the team and by that I mean that any developer can edit any part of the codebase.

This freedom typically fosters collaboration, reduces bottlenecks, and allows for faster development as well as knowledge to be spread throughout the team.

Direct Customer Collaboration

Having an on-site customer or direct access to stakeholders ensures that developers understand the requirements and the vision behind the product.

Direct customer collaboration helps to reduce misunderstandings and ensure that the product is aligned with the customer’s needs.

Professional Development

Through practices like pair programming and collective code ownership, developers are exposed to different parts of the codebase and different ways of thinking, which can contribute to their professional growth.

In simple terms, eXtreme Programming empowers developers with practices that foster collaboration, and continuous learning, resulting in higher-quality software.

How To Do Pair Programming With Pair Rotation

In the video on the right the narrator describes programmers working in pairs for two days and then rotating.

It is not necessary to follow this prescription and I’ve done this such that the rotation happened every day as well as every two days.

The how-to below mirrors the description in this video and covers pair rotations that take place every day rather than every two days.

Play Video about An eXtreme Programming (XP) 2 x 4 pair programming rotation example with two newbies and two experts working on two computers.

For this how-to, we will assume that the team starts working on Monday and consists of four developers.

Step One: Form Pairs

During the Monday morning daily stand-up meeting take a moment to determine who is going to work together for that day.

At this meeting form pairs to work on a new story or decide who is going to remain on an existing story and one software developer will rotate out while a new engineer rotates into the existing task.

In the case of an existing task, at least one developer will be familiar with the effort and we will not rotate two new people into something which is already in progress.

Step Two: Work On The Story in Pairs

Over the course of the workday, work together on one or more user stories.

Pair programming, as described here and reflected in the image below, will be performed on one computer with two keyboards as well as two mice.

Pairing should be conducted as a conversation between two people, with control of the keyboards and mice switching between the two developers as they work on solving various problems.

Step Three: Rotate!

On Tuesday morning, two of the four engineers will rotate. Similar to step one, this pair will work together for that day on one or more stories.

Step Four: Work On The Story in Pairs

This is essentially the same description is noted in step two: over the course of the workday, work together on one or more stories on the same computer using two keyboards and two mice.

Step Five: Rotate!

On Wednesday morning, two of the four engineers will rotate. Similar to step three, this pair will work together for that workday on one or more stories. In this example we should rotate the software developer who has been working on the story for the longest period of time.

Step Six (optional): Have a difficult problem? Form a mob!

In situations where a problem is particularly difficult, it may behoove us to include one or more engineers in the conversation to help us break past the sticking point.

This manner of working is referred to as mob programming and is not meant to be a long-term engagement.

Instead, the additional software engineer(s) joins the pair for a short period of time for the express purpose of getting the two engineers past the point they’re having trouble with.

eXtreme Programming Is Not For Everyone

Incorporating eXtreme Programming concepts such as Pair Programming, Mob Programming, and Pair Rotation into a software development effort has its detractors [#5, #6, and #7].

The rebuttal to this way of working tends to be that if two people are working on the same problem that means that there are two brains doing one thing when they could be doing two — sure they could but it’ll take longer than if two people focus on one thing and then blow through it and start on the next task.

Also, there are two people who can explain why something was done a certain way, and that’s important because people forget, people leave projects, etc. If a single task has one rotation you’ll end up with three people who understand what was done.

One may also assume that switching executing a pair rotation halfway through a problem would slow the whole effort down as a new software engineer arrives on the scene and has to educate themselves regarding what problem or feature is being worked on, where it’s at in the development process and what needs to be the next step.

In my experience, pair rotations do not cause any detrimental change in velocity.

Firstly we would only rotate one of a two-person team off of a task at any one time.

Secondly, it usually only took a few minutes for people to get acclimated with where the task was at that point and then start contributing to the solution.

Finally, this strategy kept things interesting, allowing developers to work on areas of the application that they may not have had a chance to do if they were focused only on one area of the application for long periods of time, and this strategy also helped to prevent burnout.

As an aside, we didn’t pair for the entire day — in some cases we would break off and work on something individually and then bring that finding or subtask back to the task at hand and incorporate the result.

Finally, mob programming helped to push through particularly difficult pain points, and at one point we had five people working towards getting a task resolved.

This was an excellent approach as the problem we had required an understanding of a certain framework and we had an expert available on the team.

We had the symptoms already identified, we voiced the observations during our daily standup meeting, and when this happened we were able, as a group which now included yet another engineer, to get this problem resolved in under three hours.

Compare this with working on this issue in an insular manner or with only a short burst of assistance here and there and it could have easily taken two weeks to get past this issue alone and the task itself was technically challenging.

eXtreme Programming / Pair Programming Conversation with Ben Smith

I had the pleasure of chatting with Benjamin Smith, a member of CTO Lunches, a few days ago and here’s what Ben had to say about pair programming:

I’ve been pairing full time in most of my gigs for the past 10 years…

Pairing encourages doing the right thing. Most teams see this come out in higher quality code, but it applies to anything. Are you more likely to write that test first when you’re by yourself or when your peer is sitting next to you? If testing is difficult for you, you might skip writing the test first or skip writing tests altogether if you are soloing. How about talking to the stakeholders to get a better understanding of what needs to be built rather than just making assumptions and carrying on? Or spending the time to figure out the performance implications of a SQL query rather than just shipping it as is.

Full time pairing removes your ego. When I’m soloing I occasionally (maybe often) get stumped by simple problems. They’re problems that I know I should be able to solve, and I know the solution is going to be face-palm stupid. I will spin my wheels for 15 minutes, then 30, and feel embarrassed when I have to ask for help after 45 minutes. My Ego is what’s making me feel embarrassed, and keeping me from asking for help the second I get stuck. With full time pairing, you cannot have any ego. If you get stuck or don’t know something, you cannot hide it. You get used to saying “I don’t know”. And when your pair replies with “I don’t know either”, you immediately get up and find someone to help the two of you rather than waiting 45 minutes. (as a side note: I don’t believe that teams that pair part time, or pair-when-it-makes-sense are able to get rid of the above ego problem).

When choosing whom will pair with whom on the team, all different match ups are productive. For example you may think that it is always a good idea to keep a junior team member paired with a senior team member, but that’s not actually the case. It is equally good to have two junior people pair up and work their way through hard problems on their own.

Pairing when neither person knows tech stack can be tough. For example: if the codebase is in React, and neither have ever done any React, then you spend your time going through tutorials, and reading documentation. Reading through large amounts of text while pairing is hard since everyone reads at a different speed.

Those are a few nuggets that immediately come to mind.”

Article Conclusion

All in all this experience was positive and I often left work at the end of the day feeling exhausted but also consistently productive, and that’s very important since one is not far from burning out when they’re going home day after day feeling exclusively exhausted.

So have you tried pair programming, pair rotation, and mobbing on any of the projects you’ve worked on?

If so, I’d be interested to hear if your experience reflects what I’ve written in this article, so please include some comments below. I’d be especially interested in hearing where this hasn’t worked, or any problems encountered when introducing this style of working.

Pairing can be especially helpful when trying to solve particularly thorny issues and one example which might help drive this point home would be when a specific error is encountered when attempting to install minikube Metrics Server — this is one example where having some assistance from a fellow engineer would likely save some time.