Ping-pong pairing is an active, turn-based form of pair programming, usually combined with test-driven development. One developer writes a test, then hands control to the other, who implements enough code to pass it. Before switching back, that developer writes the next test. The pair repeats this cycle as needed. section 11.2.2
A test-to-implementation handoff
Developer A writes a failing test for a sorting filter and passes control. Developer B writes acceptable code that makes the test pass, then prepares the next test. Control returns to Developer A, who implements the new behavior. Both developers contribute continuously instead of leaving one person as a passive observer. section 11.2.2
Use the style deliberately rather than treating its rhythm as a universal rule:
- Choose it when two perspectives add value, especially for new features, critical systems, core libraries, complex problems, architecture, refactoring, or experimental solutions. section 11.2.3
- Expect frequent switching to support mutual learning and near-even contribution; pairs with comparable skill levels may find the challenge especially engaging. section 11.2.2
- Set explicit time limits and preserve solo work. A practical starting point is 30-minute to one-hour sessions, because focused pairing can become exhausting. section 11.2.3
- Skip it for routine, repetitive, simple, or boilerplate work when a second person adds little value. section 11.2.3
Table 11.1 Pair programming pairing styles
|
Pair style
|
How it works
|
Pros
|
Cons
|
|---|---|---|---|
|
Driver-navigator
|
One driver: focuses on writing the actual code
One navigator: focuses on reviewing the code being written in real time
|
Most common; the pair has equal chances to contribute and review
|
Uneven personality matches might result in a single driver the entire session; the passive navigator might not review as effectively
|
|
Driving school
|
One navigator: focuses on giving tactical, direct, and detailed instructions to the driver
One driver: follows the navigator’s instructions
|
Can be useful if the pair has previously discussed a solution about to be implemented
|
Stronger personality might unintentionally perform this style when paired with a more timid developer
|
|
Pomodoro
|
One driver, one navigator (as in driver–navigator style)
Pair program in 25-min intervals; 20 min coding, 5 min break. Then switch roles
|
Equal participation time between the pair; naturally breaks down pairing sessions into manageable chunks
|
Constant switching might be hard for some developers; can be difficult for pairs with different skill levels
Timing might be an anxiety driver (“I only have 5 min left to finish this”)
|
|
Tour guide
|
One driver: focuses on explaining and implementing code
Multiple navigators: passively listen to driver
|
Useful for onboarding or when new implementation has to be shared with the greater team
|
Passive listeners can grow bored or “zone out” as they don’t get to participate in actual code writing
|
|
Ping-pong
|
One writes a test; developers switch; currently active developer writes code to pass the test. Writes the next test and then switches; cycle continues
|
Great with Test-Driven Development; useful for range of skill levels
|
Constant switching might be hard for some developers; can be difficult for pairs with different skill levels
|
|
Tag-team
|
One driver, one navigator (as in driver–navigator style); switch driver role as the pair sees fit
|
Casual, free-form; developers decide when to switch
|
If one favors more control or is more passive, switching may not occur as frequently
|
Compare ping-pong with driver-navigator, driving-school, and Pomodoro arrangements when choosing a pairing rhythm for a team or task. section 11.2.2
