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 and the executive director of agile42. I am supporting strategic product development and leadership challenges for more than 15 years now. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: Organic Agility, complexity, resilience, organizational culture & Agile? Just send an email :-)
blog comments powered by Disqus
Image of marion

Marion Eickmann

I am one of the founders and the executive director of agile42. I am supporting strategic product development and leadership challenges for more than 15 years now. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: Organic Agility, complexity, resilience, organizational culture & Agile? Just send an email :-)

Latest Posts

Workshops on the Certified Agile Leadership pathway

CAL 2 workshops offered in Berlin on Agile Leadership, Organizational Design, Changing Leadership, part of the Certified Agile Leadership program

Image of marion

Marion Eickmann

I am one of the founders and the executive director of agile42. I am supporting strategic product development and leadership challenges for more than 15 years now. Since 2007 I have been realizing local and global agile projects with agile42's international team successfully. You like to talk about: Organic Agility, complexity, resilience, organizational culture & Agile? Just send an email :-)

Exhaustion is Not a Status Symbol

Leverage the agile values to mitigate the risks of exhaustion becoming a status symbol

Image of melissa.boggs

Melissa Boggs

Meet The Coach: Kemmy Raji

Having worked in various sectors from financial institutions to utility companies, meet Kemmy Raji.

Image of agile42

agile42

News and views from the Headquarter of the agile42 team

Meet us at Agile People Sweden 2018

Come and join the coaching clinic with agile42 at Agile People Sweden 2018 Conference in Stockholm

Image of sofia.svanback

Sofia Svanbäck

I am the Business Relationship Manager of agile42 in Finland and Sweden. I started working at agile42 in May 2018 and haven’t done anything so interesting before. The decision to join agile42 is a decision I am proud of today. My days are filled with customer related things, like negotiations, offers, and training / coaching bookings to mention a few.

Meet The Coach: Sunny Dhillon

For our Meet The Coach series, agile42 coach Sunny Dhillon talks about his background, his agile journey,  and insights about Agile adoption. 

Image of agile42

agile42

News and views from the Headquarter of the agile42 team