2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- January 18, 2017
- Collaborate
Sometimes the practices of Extreme Programming can be a bit too extreme when first introducing them to a team. This is especially true with pair programming.
Of all the practices that I teach software developers, I get the most resistance from pair programming, Both developers and their managers are skeptical about pair programming, although each have different concerns.
Managers tell me they can’t afford to cut their developers’ productivity in half but that actually doesn’t happen. Productivity increases for teams that do pair programming well, and for a number of reasons, but most fundamentally because when people who are working together they stay focused on a task more consistently than when they’re working on their own. This has several side effects, including fewer bugs, higher quality code, and better work habits.
The resistance I get from developers is different. Their main concern is often compatibility between partners but it usually turns out we can be most productive with people who are different from us rather than the same as us. It’s the differences between us that makes for a good pair. Our differences can often complement each other. And when everybody understands the ground rules and the purpose of pairing, it can grow into a very positive experience.
I know teams who pair on everything because they find so much value in it most of the time. Of the hundreds of teams I’ve introduced pair programming to, many of them continue to use the practices. Developers love pair programming when they’re introduced to it correctly.
The trick to getting a team to adapt pair programming is often just getting them to try it. When I encounter a team that’s reluctant to try pairing, sometimes I’ll suggest another technique, which I call buddy programming.
Buddy programming is not pair programming. With buddy programming you work on your own, by yourself, for most of the day, the way traditional knowledge workers typically work. But at the end of the day you get together with your buddy and walk through the code you each wrote since the last time you were together.
You’re checking in with another person, either at the end of the day or at the beginning of the next day for maybe an hour or so and reviewing each other’s work including decisions, designs, code, questions, etc. I find that this approach can often be a gateway for developers to adopt pair programming. They find it so productive working with their buddy that they do more and more of it throughout the day until it eventually goes from code reviews to code creation.
Some teams prefer to stay with buddy programming and use it as a way of enforcing code reviews among the team. But I have seen other teams soften to the notion of pairing and move from buddy programming to pair programming as the way they work most of the time.
Previous Post: « Strong-Style Pairing
Next Post: Spike on Unknowns »