Pair Programming

Created by Kent Beck a long, long, long time ago (the mid-90s), extreme programming (XP) is a form of agile software development. It’s made of 12 principles that enhance agile development but, wonderfully, these do not depend on each other to work! Each can be introduced as slowly or as fast as teams desire! Less pressure equals less excuses (tell your boss).

At Edenspiekermann, developers gather for one hour a week to share our work and ideas. We copied this format from our previous (and ingenious) design couch idea — please read about that here!
On the couches we share knowledge, skills, and pillows. Everyone gets their turn in the spotlight to speak. I am quite fond of a particularly memorable couch where one developer suggested increasing cross-team code reviews. His desire was to improve everyone's well being through better communication. It goes without saying that he won idea of the week. Now we just need to buy a trophy.

Code reviews fall under the “collective ownership” XP principle, which advises us to share expertise on how each company project was formed, how it’s maintained, and every little thing in between. Sounds pretty difficult, right? Luckily, with a little push in the right direction, a collaborative ball began to roll and we’ve been happily running along side it ever since! Sound exciting? Yes! Please read on.

We took our first tiny, baby steps on the couches by sharing what we work on, showing it off, and then digging into the code. Low pressure, lots of insights. This humble beginning gave us some confidence to offer or ask for cross-team reviews, giving us a welcome excuse to get to know people from other teams better and be introduced to the technologies they were using. Unexpectedly, this fresh new way of working naturally morphed into something even more beautiful — pair programming! Fuelled by the increase in clarity and the lessening of confusion, developers began to communicate more — away from the dev couch and into the world of hands-on client work.

Pair programming falls under the same XP principle as code reviews and often naturally progresses from them.

“Pair programming typically means two developers working on the same code at the same time, often switching roles as writer and reviewer, helping increase code quality and team strength.”

As a new developer, I’ve found the natural evolution of pair programming within my team to be hugely beneficial. Firstly, I am much less worried about suggesting that myself or others pair on complex stories. Before, I was worried that I’d mess up other developer’s routines. Now, we have a great space where it feels safe to consider pair programming, but not be under pressure to do it all the time. The questions pair programming allows me to ask helps me learn a lot faster and as a result I’m able to confidently take on more tasks by myself.

Naturally, it sounds like a terrible use of resources for two developers to work on one task, right!? Despite this, the developers here continue to remark, in their own words, that the introduction of pair programming has been surprisingly successful. The increase in development time is slim to none, but the benefit is wide. We learn more about each other and our preferred ways of developing, trust and confidence within teams has grown, and less questions and issues are being swept under the carpet. We are able to stay true to our agile mindset — our ability to adapt to circumstances. Skills and knowledge are shared on a much more regular basis, allowing people to flourish professionally. Imagine all of these benefits for an approach that is flexible, unpressured and easy to integrate. Even if it does not work for you, there is no way you won’t learn something about yourself and your team in the process. No excuses — go and make it happen!

Tips

• Share and ask questions about code — find a comfortable group setting to begin practising this, like we do with the dev couch
• There are no set rules, pair when it feels natural — but make a small effort to initiate cross-team code reviews and see if this helps people feel more comfortable pairing
• Developers of every level can review code and pair — and it’s actually really important for your junior developers to do both!
• Try to switch roles regularly while pairing — one person ‘driving’ (writing code), and the other ‘steering’ (pointing out potential issues)

Do you want more insights into our development processes? Check out our dev blog.