I was painting my kitchen last week and it got me thinking about pair programming.
My partner and I have painted rooms together before, and we've ended up with something we've been really proud of, but when I did this alone, even though I have the skills and the knowledge, it didn't end up as good. I wondered why?
The reason is because when working on my own I am inclined to be a bit lazy, a bit casual - so long as it's "good enough", so long as it works ok, then it's fine. If my partner was here though, I'd have been the one racing out for the masking tape, because I know that between us we want to do a really good job.
Working together somehow seems to generate more pride in the quality of the work that we do. We find that we take more care because we want our partner to be proud of the job too. Even better than this - it’s actually more fun!
As I was going over the edges a bit, I noticed that the previous painter (evil previous home-owner) had also gone over the edges. So it turns out I'm actually compounding an existing problem. Do I stop and think about how I can take this opportunity to fix up the mistakes they made while I'm here? No. My internal dialogue only goes as far as "I said I'd finish this today", and so that becomes the most important thing. I’m so busy concentrating on the tactical job at hand that I don’t stop to think that I'm making a problem worse, or that it'll be a long time before I get another opportunity. Instead of fixing up small issues as I go along, I instead simply build on top of them, and relegate it to my "niggles list" (a list that only ever gets longer, and never shorter).
I also used the WRONG PAINT! Now, I know what the right paint for a hot and steamy kitchen is. I don't need a "superior" painter and decorator to tell me. What I need is someone who can be bothered, or who can make me be bothered, to go to the shop to get the right paint instead of just using the ordinary white paint in the shed.
When my partner came home from work, he "reviewed" my work. He didn't mention that I'd gone over the edges - what's the point? He's not going to ask me to do it all again, it's too late to point this out now. It's just a "learning point" for next time - though as I've said already, it's not as if I didn't already know the right way of doing it, I just didn't do it. And he didn't notice that I'd used the wrong paint - although I was honest enough to tell him, so he is prepared for the re-work next year.
So, I've finished painting the kitchen, and it looks ok, but I don't feel especially proud of it. Reviewing it with a peer at the end just highlights all the short-cuts I've taken, and makes me feel bad. These things needed to be pointed out at the time, this is just too late, and is no substitute for collaboration.
The net result is, that whilst two people painting a room together might seem like more hours being spent on the task overall, those two people would have been energised by each other into doing a quality job. Instead, one person has done an "ok" job, but it will need done again in a year's time, thus losing any economy that might have been found here.
Luckily for the house, the painters and decorators are "live-in", and so at least will still be here in a year, hopefully with a memory long enough to learn from this year's lesson. Unless something happens, we won't have moved on to somewhere else, like our evil previous home-owners, and left the problem for someone else to resolve.
Pair programming
I’m sure you can see as well as I that this can be mapped directly onto Pair Programming. The key benefits highlighted by my painting experience are:
- Increased pride in your work
- Greater motivation
- Increased focus (I neglected to mention the number of breaks I took to check Facebook…!)
- Reduced accumulation of Technical Debt
- Reduction in defects and silly mistakes
- Reduction in reviews and rework
- Joint learnings that “stick”
All of these things combine to increase the quality of the code you produce, without necessarily increasing the time to deliver. And the knowledge of the code is now held by two team members, rather than one.
Pair programming is about far more than helping a junior developer learn from a senior one - it’s about crafting the solution together.
So if these are the results of working as a pair, it is worth looking at those qualities that make up a good pairing. It’s not an accident that my partner and I work well together, there are important characteristics of our relationship that make it work.
The 6 Cs of a successful relationship pairing partnership:
Communication - It’s good to talk. It’s no good watching silently whilst your partner makes mistakes and then bringing it up every time you have a disagreement in the future! Equally it’s no good busily painting away in silence, or the observer will simply stop paying attention. Talk about what you’re doing, as you’re doing it, and create those opportunities for input. This way you both remain engaged and motivated, and you can genuinely take joint responsibility for producing something fabulous.
Confidence - Have the confidence to tackle the difficult bits, and to take risks when working with a partner. Don’t be so scared of looking silly that you don’t make suggestions, because if one of you is inhibited by insecurity, then this will not be an effective pairing.
Ron Jeffries tells a nice story here (scroll to the end) about his first experience of pairing, and the lessons he learnt from a young “whippersnapper”. Recognise the value you bring to the partnership - even if your partner is more experienced. Apart from anything else, there is great power in asking “stupid” questions, that will challenge the assumptions and habits that developers adopt over time. Suggesting a way to tidy up will not necessarily get greeted with a growl!
Compromise - To balance out the confidence, you must be willing to compromise. You need to be open and ready to accept each others’ ideas and styles as you go along. Even if you think you know the quickest route, embrace new options offered by your partner - by accepting and encouraging new ideas, you’ll be doubling the creative input rather than halving it.
Comfortable - Relax. Be positive, patient, and generous with your feedback. It’s important to establish a rapport that will enable you both to feel free to offer up ideas. Of course, this also applies to your physical space - make sure you are sitting comfortably, with clear space for your glass of wine water, a good view of the screen and that you both have easy access to the tv remote control keyboard and mouse.
Change - There are a couple of approaches to pairing, both of which bring out the importance of changing things around.
The Pomodoro technique, when applied to pair programming, will enable you to switch roles regularly, in order to remain alert and truly engaged.
With the Ping Pong approach, one person writes the unit tests, whilst the other writes the code to make the tests pass. Again, switching roles frequently is important, and you can still use a pomodoro to regulate this.
My partner drew the line at swapping partners, but you do have to keep things fresh! Promiscuity is to be encouraged. because if you are pairing with the same person day in day out, you really will drive each other mad. Rotate things round the team, swap every day or half day, and get to know all of the work that is being done. This will be the ultimate in knowledge-sharing, and cross-skilling, and has been know to work extremely well.
give it a Chance - If you’ve not paired before, this won’t come naturally. Give it a fair go - commit to trying it out for a month and accept it won’t be easy. The worst case scenario is that you’ll hate it and have a slow month, but in the best case it’ll work out and you’ll end up with a focused and energised team who together will produce something they can really be proud of.
Getting started
We’ve established that there’s much to be gained from working as a pair - high standards, joint ownership, even fun! You need to be prepared to work at it, however. Simply sitting two people in front of a screen won’t automatically produce these results - but with a bit of effort and some careful inspect-and-adapt the magic will start to happen.
If you and your team decide to give pair programming a go, there are many great resources available to help you get off the starting block, for example:
- I love this paper where Laurie Williams shows how many of the good practices for pair programming really do go right back to the playground.
- If this is new to you, here is a simple list of the right questions to be asking as you go through the process to help you approach it constructively.
- If you’re giving it a go and something just doesn’t feel right, then you can look here for some
relationshippairing guidance from Zee Spencer.
About the Author
Victoria Morgan-Smith is a CSP at the Financial Times, and has been leading teams there since 2009. Before this she was a developer for 9 years, a background which fuels her interest in finding fun ways to coach, energise and motivate teams into self-organising units. She is passionate about collaboration beyond the team, adopting agile principles to get under the skin of what will deliver measurable business value.