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).
Pair Programming Economics

Pair Programming Economics

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.

Feedback

What do you think? How do you explain the benefits of pair programming and other XP practices? Thanks for joining the conversation!.

9 Comments

  1. Professional Development – 2015 – Week 5
    February 2, 2015

    […] Pair Programming Economics (via Brendan Enrick) […]

    Reply
  2. Mohinder Khosla
    February 9, 2015

    I look at pair programming as driver/navigator left/right brain, L-mod/R-mode functions. I hope that makes sense

    Reply
  3. Five Blogs – 13 February 2015 | 5blogs
    February 13, 2015

    […] Pair Programming Economics Written by: Olaf Lewitz […]

    Reply
  4. Agile Quick Links #30 | Agile Pain Relief
    February 18, 2015

    […] Pair Programming Economics (Olaf, Trust Artists) […]

    Reply
  5. Link: Short Article About Pair Programming | Agile Advice
    February 22, 2015

    […] Pair Programming Economics by Olaf Lewitz describes three activities in programming: typing, problem-solving and reading code. How does pair programming help? By making the balance between those three activities better. […]

    Reply
  6. Ecrire du code propre – Le nommage | OCTO talks !
    April 21, 2015

    […] plus négligée : le nommage. Un nommage adéquat sera la source première de sens à votre code. Quand on sait que 70% du temps d’un développeur  consiste à lire du code, il est important d’en optimiser sa […]

    Reply
  7. Code – February 2015 | iReidCode
    July 17, 2015

    […] Pair Programming […]

    Reply
  8. Trust Artist Pair Programming Economics - Trust...
    December 14, 2015

    […] 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.  […]

    Reply

Leave a Reply