Pair Programming Is Not a Silver Bullet

Over the past four weeks I have been working with a new start up company where the owners (who are developers themselves) want to use pair programming to do everything.

In this blog post I want to share my experiences and opinions on pair programming.

This is not the first time I have done pair programming and it won’t be the last. I chose the title because when you read about pair programming in extreme programming books, the ideas look great on paper but can be difficult to implement and don’t work in the real word.

Two heads are better than one

Developers who have had positive pair programming experiences write about

  • how much more focused they were
  • increased productivity
  • better code quality
  • shared knowledge/less dependency on a single developer
  • how it helps new developers learn the ropes
  • quicker investigation and resolution of bugs
  • on the job training
  • why it’s so much better than doing code reviews

On that last point Theodore Nguyen-Cao has made an excellent observation in his blog post Pair Programming > Code Reviews

In code reviews, people sit down to review someone’s code. Everyone has an opinion but not everyone is going to be working with the code on a daily basis. At the time, everyone seems to be involved in the process but there is no vested interest. They are just looking at some code and asking themselves “does this code look good and is it correct?”. It’s a very passive standpoint. On the other hand, pair programmers are completely invested (committed?) in the task at hand. They immediately are using the code they are writing together and collaborating their thoughts on design, code layout, etc. Both programmers are taking on an active role and are emotionally invested in the task at hand because they are attacking the same problem together.

Shared Code Ownership

Have you ever been in a situation where a ‘friend’ has become so attached to their code, they find it difficult to accept it doesn’t do what it’s supposed to or is no longer required?

My best experience of pair programming has been taking over the lead development of a project where the previous developer had been working alone.

When a colleague and I came to conclusion what had be done did not have anything to do with the problem domain, we decided to delete the code and pair together to ensure the same mistake did not happen again. We continued to pair until we had a solid foundation to build upon.

When code is written by a single developer, they will inevitably end up owning it. No doubt you’ve heard something like “that’s Bobs login controller”. If there’s a bug or issue with that code the developer can become very defensive.

When a pair is told the same thing I think it’s a lot easier to deal with because no one person owns the code. In addition developers working in a pair find it easier to accept the path they had followed has come to a dead end a lot quicker than a developer working alone.

Sounds great. Where do I sign?

Hold on comrade not so fast.

Pair programming can be a bit like communism, too good to be true.

One of the most difficult things in pair programming is finding a good pairing partner. The general consensus is that developers need be at similar skill levels, understand the domain and offer something their partner other can’t.

All good relationships are about give and take

Unless you’re a total idiot and couldn’t care what your pairing partner thinks, you will be conscious how your partner is feeling.

If you hog the keyboard too much your partner will become a chicken, involved but not committed. They will play with their phone, think about what to have for dinner, or even fall asleep.

If you’re too passive, not wanting to ‘rock the boat’ you will be putting your name against something you don’t necessarily agree with. This can even be an issue even when you have the keyboard, because all you’re doing is typing what the other is saying. Lets hope your secretarial skills are up to the job.

Some of you will be quick to point out the solution to this problem is to swap the driver/observer roles every 30 minutes or by adopting the ping pong pair programming pattern.

However this doesn’t always solve the issue especially if you’re working with a control freak who says something like “why don’t you try this?” before taking back the keyboard.

In addition to changing roles within a pair, the developers in the pair should be rotated.

In the Turning on a sixpence – No excuses: Concept To Cash Every Week video, developers working on a project for a broadcasting company changed pair in morning and afternoons. This means over a course of two days five different developers would have been involved.

For example in the morning developer A would be ‘driving’, and developer B would be the ‘observer’. In the afternoon developer A, would move onto something else, developer B would be ‘driving’ and developer C would be ‘observer’.

I know this is cynical but I can’t imagine that the first few minutes of a new pair starting aren’t spent bitching about the developer who has moved on, followed another half an hour taking out what they think is wrong and doing what they wanted to do.

Developer Values

There’s no doubt a developer has to make sacrifices when pairing. What if you like doing test driven development, but your partner doesn’t? You could

  • suggest to try it out – and then try to look pleased when they don’t.
  • raise the issue – because that’s really going to help you build a relationship.
  • do nothing – it’s the easiest thing to do and you simply can’t face another day at work wasting time fighting your corner.

A good developer in a pair can’t argue with everything they don’t agree with, they have to bite their lip and let things slide. After all how much value is there in arguing if underscores should be used for private member variables.

Thanks But No Thanks

Many developers have said that pair programming is that it’s not for them.

Lionel Messi European and soon to be crowned World footballer of the year is fantastic when he plays for Barcelona. But when he plays for Argentina things don’t go so well. The problem is the system he has to fit into.

Why should a developer who is able to write good quality code on time be forced to fit into a process? After all that isn’t agile about ‘Individuals and interactions over processes and tools’.

And if you believe ‘people work harder when there is someone looking over their
shoulder’ (see Mendelt Siebenga’s post The dirty secret of pair programming), well that fits in with the Tayloristic view that workers are stupid, can’t be trusted because they don’t care about things and only managers know better.

When I’m working alone and have to solve a problem I can look on the internet Stack Overflow or ask a colleague.

Sometimes when you’re pair programming trying to find a solution is like having a back seat driver on board, you’re unable to concentrate and have to speed read because your partner wanted to click on a different link or search for something else. This clip sums up what I mean.


Harry Enfield Television Programme – You Didn’t WannaA funny movie is a click away

On a lighter note some developers have pointed out they don’t like pair programming because to hygiene issues. Sharing a keyboard and mouse with someone who doesn’t wash their hands, or having to sit in close proximity with someone who smells, is not a pleasant experience.

Jag Reehal’s Final Thought on ‘Pair Programming Is Not a Silver Bullet’

Should developers do pair programming all of the time? No.

Developers should be trusted and left to their own deceives. They should pair when they think it’s the right thing to do.

When pair programming works it’s very good, not only for the project but for individuals as well. The amount of keyboard shortcuts and tips and tricks I’ve picked up when pairing is amazing. Check out Keyboard Jedi when you are pairing, it shows a visual list of shortcuts as they are being typed.

It’s important that developers are able to read blogs, explore and experiment, which pair programming doesn’t really allow for because your partner has to agree with everything you want to do. In his PDC 09 ASP.NET MVC 2: Ninjas Still on Fire Black Belt Tips talk Scott Hanselman said ‘you can spot a good dev if their recent project list contains projects where they are just trying out stuff’.

For me code reviews come too late in the development process. Pair programming should seriously be considered if code reviews are of paramount importance to you.

As for the arguments about productivity and focus etc, yes it can help. But I also believe developers working alone and using the pomodoro technique could achieve similar results.

I will never dictate my team have to do pair programming. But I would be disappointed if they never tried.

Excellent FREE resource for learning Domain Driven Design

If you asked developers what books they should read, most would (or should) include Domain Driven Design by Eric Evans.

Why is it important?

The patterns and practices outlined in this book will help you develop more successful software solutions.

How?

Eric Evans shows how you can improve communication with your customer (by doing things like developing a ubiquitous language), implement agile practices and create maintainable solutions which follow good software development principles.

One of common criticisms of the book is that ‘it does go on a bit’.

The good news is that the folks over at InfoQ have come up with ‘Domain Driven Design Quickly’ which summarizes what Domain Driven Design is about.

The even better news is that it’s FREE if you register with InfoQ, which is no bad thing because it’s a fantastic resource with videos, presentations and some very good articles.