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

Why are organizations not seeing the benefits of doing Agile?

Due to a difference in goals and approaches, friction occurs between Agile teams and the rest of the organization - who has yet to see the benefits...

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.

Agility requires cultural change

Article published in German magazine

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.

Agile in Everywhere: Sales

An experiment as a ScrumMaster and Agile coach working with a Sales team, where Agile practices are supporting new acquisition and retention targets

Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.

Good VIBE at Scrumtisch Berlin

Scrumtisch March 2018 at SAP Berlin

Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

Step up your Kanban game

In the upcoming weeks, Accredited Kanban Trainers from agile42 will facilitate certified Kanban training in locations all around the world

Image of mikefreislich

Mike Freislich

Image of rhilll

Russell Hill

Image of mgaewsj

Gaetano Mazzanti

My background includes a long experience as a manager in the Software and Machinery Industry. I worked in USA and India leading distributed teams in advanced software projects (CAD/CAM, PLM, Industrial Automation, Plant Control and Supervision). As a coach I am now trying to help organizations to change embracing Agile and Lean values and principles. I am a WIP limit addict :) and a KCP