Pair Programming Pros and Cons

Sunday, 04 July 2010

Pair programming is a bit of a marmite concept the development community - you either love it or hate it. Some developers swear by it while others can not believe it’s practiced. I’ve worked under both extremes and right now I do a little of both so I thought I’d share my findings.


Pear Programming

You always have two people who know the inner working of a feature. So if one is not around or leaves then the knowledge is retained.

New team members can be more quickly integrated as they can immediately work on new features with more experienced developers. Knowledge spreads fast.

Want to introduce a new language or technology to the team? There is no better to get the ball rolling than to implement a new feature as a pair using it to get the rest of the team onboard.

Having a couple of pairs programming and one individual who deals with incoming internal and external information/development requests can effectively eliminate all interruptions. It leaves the pair to continue being productive and alleviates the problem of multiple people chipping in on an issue and disrupting the whole team.


The simple fact is not everyone gets along. Be it personality or programming style - working on something and having a lot of disagreements is not much fun.

You need to be especially careful when hiring new people. It’s very hard to gage how someone will fare day to day in an interview and even harder to gage how they well they work with others. Hiring slightly the wrong person can ruin a team’s flow.

Sometimes we all need a little space and a little room to breath for whatever reason. It’s hard to get any if you have to pair all day everyday.

Sharing computers and desks is awful. What if everyone needs to use the computer at lunch time and there are not enough to go around?1 What if you have carefully configured some apps on one machine but someone else is using it today?

Some people are not as hygienic as others and you will be using the same keyboard and mouse - be prepared to share coughs and colds. Some people are tidier than others, leaving food and other things on the desk is no problem if it’s your desk but can be quite annoying for others.

It’s much slower. Talking through approaches and trying to agree on an implementation takes up a fair amount of time. Sometimes you just want to knuckle down get something done - not gonna happen. Obviously the two people could be programming in parallel on different problems.

Design by committee is known to be a bad practice and yet pairing is usually done on front end (user facing) interfaces too. This leads to messy and overcomplicated screens that should be clear and well thought out.

The Verdict

I’m going to cop out at this point and say it depends on personal preference. It’s important to stress that which ever system you choose - stick to your process and go through regular reviews with the team to iron out any kinks.

  1. Of course the best way to solve this is for each developer to have a personal laptop. This can be off to the side for looking up documentation and personal use while the main computer remains in the centre for programming.

blog comments powered by Disqus