Pair Programming Economics

Posted by on Jan 27, 2015 in Agile with a Purpose, Conference, Programming | 11 Comments

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!

11 Comments

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

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

    Reply
  3. 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
  4. Five Blogs – 13 February 2015 | 5blogs
    February 13, 2015

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

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

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

    Reply
  6. 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
  7. 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
  8. Code – February 2015 | iReidCode
    July 17, 2015

    […] Pair Programming […]

    Reply
  9. 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
  10. Peter
    October 25, 2016

    I totally agree with you. Many managers still have the problem that they think about developers as a coders. That means, your job is to code 8 hours a day. This is faaar beyond the reality, mainly in Agile environment. I propose pair programming in our team often and also there is heavy resistance from the team. Mainly from developers who have never tried it. Why is that? Because they have same thinking as management that came from traditional development, that their job is to code and they can do effectively only by coding independently. Fortunately, if any of them tries to do pair programming there is almost instant love for it and it produces value much faster than if they do coding separately.

    Reply
  11. Jesper Vehn Munk
    June 21, 2017

    In my team we use pair programming for two main reasons: doubling up on the brain trust, as you correctly state, and for the learning experience of one dev sharing some knowledge with the other. The latter works better than any set of tests or written documentation.
    As a consequence of having seen that, we’ve started the occasional mob programming as well.
    Primarily when starting new, larger scale projects/epics. It helps the entire team understand the very foundation on which we’ll be working.

    And to the concerned PO’s out there: the “lost” work hours from X developers looking at one keyboard, are made up for X-fold in the work to come.

    Reply

Leave a Reply