Pair programming, I used to heard a lot about it.
Some said, it is fun.
Some said, it produce good and clean code.
Some said, you can learn from your pair everyday.
Therefore, When I have chance to join a pair programming shop. I took the offer without any hestitation.

So after 7 months of pair programming. I thinks it’s a good time to talk about it.

Pair programming

Pair programming is an agile software development technique in which two programmers work together at one workstation.
One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in.
The two programmers switch roles frequently.

~ from wikipedia

Pair programming, is one of the most controvesial agile practice.
Even most of the company is running agile now, there are not many company take full pair programming pactice.

One of the reason might because pair programming is hard.
It requires constantly communicate and discipline between developers.

For example, when your pair is not focus, like he drink too much in the party last night.
It will effect the team more than working alone.
The result depends on the skillset and communication skill of your pair,
sometime it can produce good code and get lots of things done, sometime you would think it is not better than you work alone.
So it depends a lot about chemestry among pairs.

How we pairs

We work on a 2 27` desktop mac workstation with 2 keyboard and mouse set.
with an daily stand up at 9:15, which we usually decide and rotate pair at that time.
Then pairing to 5:45 with a cross team standup to share what happened and what we learned today.

Benefits

• Constantly review

In my opinion, the main difference between pairing and solo is, 80% of your typo will be catched by your pair.
Which surprised me when I found so much typo during solo. So debugging is easier too, have a second perspective is helpful
in avoid errors, and produce lesser bugs.

• Higher quality

On the design side, pairing usually can have more solution than solo.
However, the code quality still depends on how good the developers is.
We will still produce bad code in pairing. The more experienced developer in pair decide upper limit of the code quality.
If a junior developer pair with senior developer, it sure can prevent lousy code.
However, when 2 developer have same experience facing a hard problem.
The code quality won’t be that different than solo.

• Focus

When pair programming, people can’t surf internet and watch facebook?
Thanks for the smart phone, we can still check our facebook and email in pairing.
If you don’t care about your pair, You can spend all of your time reading tech news and funny article when working.
However, generally is harder to not be focus in pairing than solo,
but people can still get distracted by email, internet and meeting.

• Sharing context

In pair programming, people share their context between pairs, it also leads to collective code ownership.
In our team, we rotate pairs often, also rotate people to other teams. To let context can flow between developers.
In 7 months, I rotated in 2 teams, each time I started in a new team.
I can easily learn the context from my pairs and be productive.
Also for developing features, we rotate the pairs and share the knowledge so every dev can take over the development
when someone is off or rotated out.

• Learning

Pair programming have more chance to learn from your pair.
From design skills to shortcut keys, every new pair is the good source to learn new things.
We also share things in cross team standup to spread ideas.

Cons

• Slow

Pairing is slow, period. A lot of time, when you have a new pair on working feature.
Usually you spend couple of hours to explain the context before you can start to work on it.
Also when writing code, you spend time to explain your thought and discuss the implmentation with pair.
It is acceptable price to improve quality and share context, but still it slow down the time to finish a feature.

• Restriction

Pairing require some hardware and editor settings, and restrict the time to work and what to work on.
You can’t read tech article, write tech blog and test new ideas while pairing.
Also, you need to be more disipline and focus on work. (which is good actually)
When your pair is sloppy or underperform, you will be effected too.

Conclusion

Pairing is not silver bullet, code is still complex and question is still hard.
The quality and speed is actually depends on person more. A good developer can deliver things either pairing or solo.
However, pairing is a great way to build team culture and share context.
In 7 months of pairing, I learned a lot from my pair, and improve my communication skills to describe technical problems.
Most of all, I know better on my coworker because of pairing and like to pair with them.
That’s the most important thing for a team isn’t it?

PS. Marshall is awesome (I promised to mention how awesome pair he is in my pair programming article)