Just the Two of Us

Affects of Work Environment on Pair Programming Productivity

Lennon and McCartney. Tom and Jerry. Macaroni and Cheese. Life is filled with famous duos. It is indeed true that two heads are better than one. Collaboration in all forms allows for diversification of thought that more often than not contributes to a better solution.

It is this same notion that drives the driver navigator relationship of pair programming. With origins rooted in XP, it allows for programmers to work together on all code writing tasks. Despite adoption challenges, firms that actively practice pair programming state many benefits.

Pair programming has been known to yield productivity benefits, if work environments support it effectively

This week I was excited that some local developers were trying our pair programming without encouragement from myself. For us this is a long time coming. Hence my exhibition of extreme enthusiasm. Overall results were positive, minus identification of a few workspace specific quirks. This week I reflect on environmental factors that affect pair programming productivity, that encourage our continued solo programming efforts.

Two Hearts

Although not directly related to workspace, it is important to note that developer attitude is important. The personality traits of the team are just one environmental factor that affects pair programming adoption.

Alone we can do so little; together we can do so much.

Helen Keller

You can lead a horse to water, but you can’t make them drink. Stubborn software engineers who prefer solitary coding are not an isolated opinion. The team cannot just leave that individual to work alone. One toxic perspective will spread throughout the developer population. Not just in causing dismissal of practice, but also in the accumulation of tension. Emptying open minded programmers is the sole method to prevent the accumulation of hostility.

When Two Worlds Collide

In an ideal world, development teams are co-located to strengthen collaboration. Certainly our ongoing strategy is to try and reduce the number of regions over which any given team expands. With current expertise spread across the globe, co-location is a not so distant dream. This makes full pairing on all features challenging.

Organisations need to invest in powerful collaboration tools to support cross-regional development. Screen shares and phones are a great initial step. They will allow a common view of the code. Many also have integrated features such as digital whiteboards that, where exposed can help with design. Regardless, these tools will not guarantee a successful pairing.

Sharing across regions is a necessary evil that makes pairing problematic

Building rapport over the phone is difficult. Psychologists suggest rapport is built more quickly when eye to eye contact between people is established. Pairs are regularly rotated, so building a rapport quickly is important to produce productive pairs. Web cams can help build strong developer relationships across regions. In addition to pairing, they can also be utilised across stand ups and retrospectives alike to build team bonds.

Two Old Friends

Assuming the regional and opinionated impediments have been removed, we must also consider the physical barriers. Collaborating across a single machine means individual workspaces must support two people sitting and viewing code.

Pedestals are the biggest physical impediment that we have to at-desk collaboration today. The traditional drawers stick out like a sore thumb, enforcing a single seat rule at any desk. This leaves your observer squinting at the code from further back. Or sitting on the pedestal and perching over, which is also not ideal.

Pedestals are the biggest physical impediment to pair programming that we currently have

Monitors must be height-adjustable and able to rotate to share code effectively to adjust to different eye levels. Even this doesn’t solve the pedestal problem. Under desk pedestals to allow space for chairs should be preferred so your moveable chairs are useful for more than just chair races. Or a pedestal stool hybrid, subject to health and safety constraints (yes really).

Two Minutes Silence

Be mindful of the sounds of the environment as well as the sights. The environment should not share the buzz of conversations. One of the biggest issues with our open floor setup is the travel of noise. Laughs and repartee reverberate across the area. It’s not the first time that I’ve been vocal about the need for noise cancelling headphones to support concentration, both in blog and in person.

Even when conversing, programming requires significant thought. Therefore the environment needs to reduce the transfer of noise. Consider noise reduction technologies to drown our the noise. Furthermore, be mindful of the layout. Consider clustering teams together in small huddle spaces to reduce the buzz of irrelevant noise. Drop in booths are great to escape, but reliance on them for a full day of pairing is not sustainable.

Noise cancelling mechanisms, combined with considered layout, are required to reduce the noise from coding discussions

Pair programming requires a balanced ecosystem to ensure ease of practice and attainment of benefits. Attitude, co-location and workspace considerations are just as important as management buy in to foster this collaboration technique. Note I suggest it is supported and not explicitly enforce. Hopefully our first foray into elective pair programming will yield benefits. Watch this space!

Thanks for reading!

%d bloggers like this: