Key practice: pairing / whole-team programming

Key practice in effective product development culture.

—

Prompt: “Create an abstract image representing pair programming”

Pair programming is two programmers working together on the same problem at the same time.

NOTE: Although the Agile Alliance includes sharing a single workstation as part of the definition, I don’t consider this required. For example, remote pairing and head-to-head pairing (pairs face each other on their own machines).

Whole Team programming (aka mobbing or ensemble) is a team of people working together on the same problem at the same time.

What problems does pair (or whole team) programming solve?

The constraint is not typing speed

Typical sequence for programming:

1. Understand the problem;
2. Understand the existing code;
3. Design the change;
4. Type it in;
5. Validate that the change works;
6. Clean up;
7. Repeat

Most of the constraint in programming speed tends to be around understanding and designing, not typing. Adding additional brains can help accelerate understanding and designing.

Continuous review

Typical sequence for asynchronous code review:

1. Write code;
2. Submit code for peer review;
3. Wait for a reviewer to respond (sometimes days);
4. Reviewer adds comments — asynchronous back-and-forth (sometimes days);
5. Fix code if necessary

Typical sequence for synchronous, continuous review when pair (or whole team) programming:

1. Write code and review it immediately.

Balancing peaks and troughs

Energy levels naturally ebb and flow when programming. When, when one programmer’s energy levels ebb, the pair can pick up the slack and vice versa.