Skip to main content

My view on Pair Programming

ยท 4 min read
Pere Pages

pair programming

Pair programming is a collaborative strategy that has gained traction in the software development world. It involves two developers working together on a single task, with one taking the lead and the other providing support. This approach is not just about sharing the workload; it's about leveraging the collective expertise to drive efficiency and quality.

My Perspective

In this article, I'll share my perspective on pair programming, exploring the key stages and strategies that underpin this collaborative approach.

  1. Task Allocation and Leadership
  2. Acceptance Criteria
  3. Exploration through Proof of Concepts (PoCs)
  4. Convergence and Decision-making
  5. Refactoring and Continuous Delivery
  6. Repeat

Task Allocation and Leadershipโ€‹

The foundation of successful pair programming lies in task distribution. Each assignment is tackled by a pair of developers, with one taking the lead. This ensures a balanced sharing of responsibilities and expertise, setting the stage for a harmonious collaboration.


Acceptance Criteria (BDD Tests)โ€‹

Clear expectations are essential to the process. Defining the task scope and setting acceptance criteria is the first step.

Behavioral-driven development (BDD) enters the scene here, providing a structured framework for crafting acceptance criteria. At this stage, think of it as a skeletal structure laden with to-do markers.

Declarative Tests for Confidence

An indispensable aspect of these merge requests is the inclusion of declarative tests. These tests serve as guardians, verifying the integrity of the changes made. A best practice is to keep these merge requests succinct - under 10 files - while injecting them with declarative tests to bolster confidence in the modifications.


Exploration through Proof of Concepts (PoCs)โ€‹

This is where the creativity ignites. The developers engage in exploratory exercises, playing with ideas and dissecting potential solutions. These proof of concepts (PoCs) serve as prototypes, helping to unravel different paths to success.

Exploratory Phases

The exploratory phase is a critical juncture in the process. It's a time for the developers to immerse themselves in the task, experimenting with different approaches and evaluating their feasibility. This phase is a testament to the power of collaboration, as the developers bounce ideas off each other, leveraging their combined expertise to navigate the complexities of the task.

You can do it on parallel branches, and then compare the results. This way, you can see the pros and cons of each approach and make a more informed decision.


Convergence and Decision-makingโ€‹

Once both developers have delved into the PoCs, it's time to compare notes. Their findings are shared, and a mutual decision on the optimal approach is made. This collaborative dialogue ensures that the combined insights lead to an informed choice.


Refactoring and Continuous Deliveryโ€‹

With a strategy in place, the real refactoring journey begins. This might entail multiple merge requests, each a compact package of changes. The mantra here is to keep these requests small and focused, adhering to the principle of a single responsibility. This approach aligns with the concept of continuous delivery, where incremental changes ensure a steady stream of improvements.

Continuous Delivery

Continuous delivery is a cornerstone of modern software development. It's about breaking down the development process into bite-sized chunks, each delivering a tangible improvement. This iterative approach ensures that the software is always evolving, with each merge request contributing to its growth.


Repeatโ€‹

The process is cyclical, with each iteration building on the previous one. The developers continue to work in pairs, leveraging their collective expertise to drive the project forward. This iterative approach ensures that the software is always evolving, with each merge request contributing to its growth.

I recommend splitting the tasks into small, manageable chunks. This way, you can ensure that each merge request is focused and concise, making it easier to review and integrate. This means that you might also need to split the task tickets into smaller ones, so you can have a better control of the progress and the quality of the code.


Conclusionโ€‹

Pair programming is a powerful strategy that harnesses the collective expertise of developers to drive efficiency and quality. By working together, developers can leverage their combined insights to navigate the complexities of a task, exploring different approaches and making informed decisions. This collaborative approach ensures that the software is always evolving, with each merge request contributing to its growth.