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.
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
Professional Development – 2015 – Week 5
February 2, 2015[…] Pair Programming Economics (via Brendan Enrick) […]
Pair Programming Economics
February 9, 2015[…] Reference Website http://c2.com/cgi/wiki?PairProgrammingEconomics https://trustartist.com/2015/01/27/pair-programming-economics […]
Mohinder Khosla
February 9, 2015I look at pair programming as driver/navigator left/right brain, L-mod/R-mode functions. I hope that makes sense
Five Blogs – 13 February 2015 | 5blogs
February 13, 2015[…] Pair Programming Economics Written by: Olaf Lewitz […]
Agile Quick Links #30 | Agile Pain Relief
February 18, 2015[…] Pair Programming Economics (Olaf, Trust Artists) […]
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. […]
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 […]
Code – February 2015 | iReidCode
July 17, 2015[…] Pair Programming […]
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. […]
Peter
October 25, 2016I 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.
Jesper Vehn Munk
June 21, 2017In 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.