Sept. 9, 2010

agile15: Pair Programming: Why and When?

In pair programming, two developers work together in front of one screen (or two, as long as they both look at the same screen) to get a task done faster and with higher quality. Just like a driving a car, there are two roles in the pair: The driver, who has the steering wheel, aka the keyboard in her hand, and the navigator who knows where to go and which crossroads lie ahead. As you want to switch these roles every now and then, it is very helpful to have two keyboards and mice attached to the computer you are working on or use a tool like Mango Lassi on Linux or teleport on OS X.

So why would you do work in a pair?

Fight distractions

Usually, you are not developing in a vacuum sealed room, so there will be colleagues, chats, telephone, and so on. If the navigator takes care of answering these interrupts (or at least deferring them to later), the driver can stay in the flow of writing code, and it will be easier to remain in the mindset of the task at hand. Getting back into a complex thought takes a while as we know.

Knowing what's next while assuring code quality

The navigator does not have to care about how to auto-complete the current function, or minor details of coding. He or she can rather keep track of the next steps, which leads to less corner cases that are being forgotten and to better test cases. The immediate code review will usually produce better designs and better readable code because all work is being challenged immediately.

Knowledge sharing

Pairing is also a tool to learn and share knowledge. A pair can get inspired and learn about new technologies or new code together, and later on split up and continue to read further details. In this case, both developers start out with about the same level of (possibly little) knowledge and try to increase it as fast as possible. On the other hand, you can also learn from your co-developer: Someone who may have more experience in one area is a great navigator who you can tap while producing even greater value. Areas of knowledge that can be shared include experience in a different area of the product, or with a tool that is used to develop, or with an engineering practice, domain knowledge, or even specialized development knowledge (interface design, patterns, testing, etc). Sharing knowledge is the best way to establish collaboration as well as reducing the risk for the whole team in case one team member may become unavailable.

While pairing can be used extensively, sometimes it may not be the right tool for every situation.

Little complexity

If the task at hand bears little complexity and risk, usually its solution is very clear and well understood. In this case, pairing has very little effect on the quality of the product. Some drivers may not need a navigator to do a simple u-turn.

Distributed teams

Remote pairing just does not work as effective as local pairing yet. You can have audio and video conferencing, but I have yet to see good (and cross platform) editor/IDE integration. Without those, the navigator may get stuck with screen sharing that suffers from time lags. Plus, if you ever communicated line numbers, you know the pain.

Stealing the wheel

Good pair programmers need to learn to discipline themselves. Focus on the task is key (not on the recent vacation, or watching funny videos), but navigators must also refrain from abruptly stealing the wheel, eh, the keyboard.

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.
blog comments powered by Disqus
Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Latest Posts

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.