Cookie Consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyse site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Pair programming: Dave Farley on how to find a balance

Kriya Team
November 27, 2018
6
min read
Share this:

In this series, our engineers ask Dave burning questions about everything from pair programming and trunk based development to continuous delivery and more.

In the spirit of one of our core values, #AlwaysBeLearning, MarketFinance has teamed up with continuous delivery thought leader, Dave Farley, on a series of Tech Blogs. Our engineers have asked Dave a few burning questions about everything from pair programming and trunk based development to continuous delivery and more. This week’s question comes from Senior Software Engineer, Mason L’Amy:

“Pair programming has been shown to increase quality and reduce overall development time. Nevertheless, some people need heads-down focused time on a problem. How do you balance this?”

My preference is to strongly encourage teams to adopt the norm that most work will be done working in pairs, but not to make it a rule. I think it right to leave room for people to decide for themselves when it doesn’t make sense.

However, you are right, ALL of the data that I have seen from studies of pair programming say that it produces higher-quality output, and so in the long run, is significantly more efficient in delivering new code. More than that, I know of no better way to encourage collaboration, learning and continual improvement in a team than pair programming.

So it is strongly in a team’s interest to adopt and encourage pair programming as the norm. It is not good enough to reject it because some people don’t like it. That would be like mountain rescue teams rejecting the use of ropes because it is annoying to carry them up the hill. Some things have value even if they take some work.

For me, this means that it is worth some effort, maybe even significant effort, for a team to adopt, learn and make pair programming a fundamental part of their development culture.

My experience has been that most people, before they have experienced it, are nervous of pairing. In part I think that this is a cultural thing, we “program” people to imagine software development as a lonely introspective act. I don’t think that good software development is really like that. It is, at its heart, a process of learning.

We learn best when we can try out new ideas and quickly discard the bad ones. One way to test ideas is to bounce them off another person. So pair programming provides us with a mechanism to quickly and cheaply exercise ideas and weed out some of the bad ones.

There are also some individuals who will always find pair programming stressful. If I am honest, I believe that these individuals have a more limited value to the team. They may have value, but that value can’t be as much as someone of similar skill who learns faster and teaches more.

Introverted people are more sensitive to stimulation than others, and so need more quiet time to reduce the cognitive clutter. I am one of these people. I need, periodically, to be on my own to organise my thoughts. This doesn’t mean that people like this can’t take part in pair programming, it does mean that you have to give them some space, some of the time.

So, my idea of “optimal” is to do most, nearly all, development work in pairs but allow humans to be human. If someone needs time to form their thoughts, or learn some tricky concept alone, or just needs some quiet time to recharge for a bit, give them that time.

There is another important aspect to this. There is some skill to pair programming. It takes time to learn some of the social aspects. For example, one very common behaviour that I see, in newbies, is for my pair, when I am typing, telling me letter-by-letter when I make a typo or what the instruction is. They are trying to be helpful, but they are not.

Watch your own typing for a bit. If you are anything like me, then your typing will progress forwards and backwards as you make little mistakes and then correct them all of the time. When this happens you know, as you type, that you made a mistake. Most errors you corrected immediately. Someone telling you at this point, actually slows you down. It interrupts the flow of your thinking – and it is irritating.

So when you are pairing, and you are not typing, give people a chance to spot, and correct, their own mistakes. Only mention a typo when the typist has moved on and clearly missed it. Only mention the correct use of a language construct or api call if the typist is clearly stuck. Otherwise KEEP QUIET!

The classic description of the roles in pair programming are “Driver” (the person who is typing) and “Navigator” (the person who is not). This is a bit crude, but close. If you aren’t typing your focus should be on the direction of the design rather than the typing.

The other important aspect of pair programming as a learning activity is to regularly rotate the pairs. Change pairs often, don’t allow pairs to become stale. My preference is to change pairs every day.

This sounds extreme to some people. It means that nearly everyone works on nearly everything that the team produces over the period of a week or two. It means that you get to see different people’s styles of working (and pairing) and learn from them. It means that you get to work with the person on the team that you find trickiest to pair with and with the person that you enjoy working with the most, on a regular basis.

Pairing means that you are working in very close proximity to other people. Think of your pair as a team, you have shared goals and will succeed, or fail, together. Be considerate, be collaborative, be kind!

If you get this kind of stuff right, then the barriers to pair programming begin to reduce. Even the introverts on your team will not only take part, but will benefit from it. Pair programming takes time to adjust to. This is not something that you can try for a day or two. It takes a while for a team to get really good at it, so allow yourselves the time, don’t give up too soon.

Dave Farley is a thought leader in the field of continuous delivery, devops and software development in general. He is co-author of the Jolt-award winning book ‘Continuous Delivery’ as well as a regular conference speaker and blogger. An early adopter of agile development techniques, Dave has been employing iterative development, continuous integration and significant levels of automated testing on commercial projects since the early 1990s. Today, he is the founder and MD of Continuous Delivery Ltd where he works as an independent Software Consultant.

B2B Payments to boost your growth

To learn more about our payments and digital trade credit solutions book a call with us today.
Email is invalid.
Please use your company email address.
Annual Revenue*
We’ll use this information to get in touch with you about our products and services in accordance with our Privacy Policy. You can unsubscribe at any point. By submitting, you acknowledge we reserve the right to work with businesses that have been trading for a minimum of 12 months and have submitted at least one set of financial accounts.
Thank you. A member of the team will be in touch.
Oops! Something went wrong while submitting the form.

Explore related posts

Kriya Lending
Apr 20, 2023

Barclays Business Health Pledge Masterclass: Working Capital Solutions

Our CEO and Co-Founder, Anil Stocker, shared his expertise on the topic of alternative financing with Chris Forrest, Head of SME UK, Barclays Business. Find out how invoice finance can help!

Kriya Team
1
 min read
Read more
Industry Insights
Mar 22, 2023
Kriya's risk approach

Kriya’s risk approach in uncertain times

Our Chief Risk Officer, Michael Hoare reflects on the current economic landscape from the Risk team perspective

Michael Hoare
3
 min read
Read more
Industry Insights
Jan 17, 2023
Anil Stocker, Co-Founder and CEO at Kriya, on businesses in the UK in 2022 and 2023.

Reflections on 2022 and looking ahead to 2023

How companies can navigate their business finance in 2023 and take advantage of key trends such as embedded finance

Anil Stocker
4
 min read
Read more