Book Image

Practical Remote Pair Programming

By : Adrian Bolboacă
Book Image

Practical Remote Pair Programming

By: Adrian Bolboacă

Overview of this book

Remote pair programming takes pair programming practices to the next level by allowing you and your team members to work effectively in distributed teams. This helps ensure that you continuously improve code quality, share equal ownership of the code, facilitate knowledge sharing, and reduce bugs in your code. If you want to adopt remote pair programming within your development team, this book is for you. Practical Remote Pair Programming takes you through various techniques and best practices for working with the wide variety of tools available for remote pair programming. You'll understand the significance of pair programming and how it can help improve communication within your team. As you advance, you’ll get to grips with different remote pair programming strategies and find out how to choose the most suitable style for your team and organization. The book will take you through the process of setting up video and audio tools, screen sharing tools, and the integrated development environment (IDE) for your remote pair programming setup. You'll also be able to enhance your remote pair programming experience with source control and remote access tools. By the end of this book, you'll have the confidence to drive the change of embracing remote pair programming in your organization and guide your peers to improve productivity while working remotely.
Table of Contents (14 chapters)
1
Section 1: Introduction to Pair Programming
5
Section 2: Remote Pair Programming
9
Section 3: Tools to Enhance Remote Pair Programming

Pair programming cannot solve everything

Until now, I have rather praised pair programming. But like any tool and any practice, there are situations where pair programming won't work or solve anything. Let's look at some usual situations.

Unclear requirements

There's a saying in software development: junk in, junk out. When you have unclear requirements, the obvious pain is not improving your production tools or practices, such as learning how to use pair programming. And pair programming will not help at all with unclear requirements.

The alternative is to have good, high-quality requirements. But be careful: we don't need to get back to waterfall and linger for 1-2 years just to document everything. When talking about high-quality requirements, there needs to be a fine balance that we can define as the simplest, shortest requirement so that the team can get to work immediately, without asking for clarifications.

So, this concept of clear requirements...