Pair Programming Economics
I’m at OOP this week and had the pleasure yesterday to meet James Grenning for the first time. We had an inspiring conversation last night exchanging tips and strategies on how we inspire developers to try XP practices like TDD and pair programming.
I really like his approach for TDD. James asks devs at the beginning of a course: List what you like about developing software, and what you don’t like. After practicing TDD in the course, students have learned that TDD helps them spend more time on the things in the first list and less on the things in the second…
Pair Programming Saves Time
How do we spend our time when we develop software? My rough heuristics is this: We spend
- 70% of our time reading code and trying to understand it,
- 20% of our time solving problems, creating solutions, and
- 10% of our time actually writing code (aka typing).
This model has been convincing to managers and devs alike:
Managers understand that their concern that two expensive minds will be wasted using only one keyboard is based on a misinformation. The one keyboard for two pairs of hands can only be a limiting factor if we spend most of our time typing.
90% of our work is more effective using two minds:
- We will understand the code faster which we want to change, and be more courageous in changing it so we may move forward faster.
- We will solve the problem faster and potentially find a better solution more quickly as we have more available options in two brains.
- While one of us is typing, the other’s awareness increases quality: catching mistakes faster than the compiler/the tests could.
What do you think? How do you explain the benefits of pair programming and other XP practices? Thanks for joining the conversation!