Ok so I’m about a month behind. Over on Coding Horror Jeff Atwood asked “I can’t help wondering if pair programming is nothing more than code review on steroids”. In a word ‘No’.
Code Reviews
…(and I’ve done many) are static. One or more people study the code often long after it was written and attempt to understand it. Most code reviews I participated in are very shallow. We tend to find simple issues that tools like PMD and FxCop could find for you: variable could be final, public method could be private etc. At their very best I’ve seen methods (and sometimes classes) rewritten in response to a code review. Rarely do I see the design questioned. In addition it’s often tough to spot the forest for the trees – buried in the minutia of a class the bigger questions don’t get asked – does this class need to exist? Etc. Finally simplifications of lead to more simplifications but due to the static nature these won’t be found.
Pair programming
…on the other hand is dynamic. It’s an ongoing conversation between two partners.
- One partner focuses on the details – what test case am I’m writing now, what’s the minimal amount of code that I need to satisfy the test. While the other partner is focusing on the big picture: What’s the best design for this problem.
- It’s not just a code review, but ongoing design review.
- Changes are made in real time so as simplifications are made new ones are easily spotted.
- When one member of the pair is stuck the other can step in with an idea.
Some additional benefits:
- Spreads the knowledge of the code base more widely.
- More people are aware of problems as they develop.
- Helps raise everyone’s skill level as pairs learn tricks from each other.
- Reduces the number of places where only one person understands what’s going on.
- Fewer bugs – about 15% fewer according to a study by Alistair Cockburn and Laurie Williams (PDF)
One point which Jeff definitely has right – it’s hard work. Pairing for eight hours a day is not an option. Most pairs work in two-hour blocks twice a day. For a more detailed article see Jeff Langr: Pair Programming Observations
So, Jeff, if you want to discover the benefits of pairing in person (or over a remote connection) give me a shout and we will arrange something.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Could you provide some more insights on how you do pair programming over a remote connection?
We do some pair programming but only with people at the same location which leads to some kind of “site-local knowledge”.
As you say, pair programming happens in real time.
My biggest problem with static code reviews is that they happen way too late. I’ve been in code reviews where people make perceptive comments about the design, but the code is already in QA, so there’s nothing you can do about it. Even on the other end of the spectrum, where people just want aesthetic improvements to the code, there’s a reluctance to actually implement the changes.
If pair programming is not an option, then I would schedule code reviews for halfway through the implementation, even if that means the final code doesn’t get reviewed. At least then the code review could help steer some of the implementation in a meaningful way.
1. Is the “15%” a comparison of pair vs. review, or pair vs. solo?
2. Is there independent validation of any of the other claims (spreading the knowledge, raising skills levels, etc.)?
Stefan: pairing over a remote connection – I use Real VNC (or any other VNC). The other developer can see my machine and has much control as I do. Caveat Emptor – this is huge security risk, don’t run the server when you don’t need it. Only run it over an internal network or VPN, ….
BTW its not like the real thing. Nonetheless if you’re not sitting together its better than a boot to the head.
Greg: I don’t know much about the details of the study. The other claims are merely based on mine and other’s experience. As I recall you’re a prof – you have students maybe you could run experiements on them. I must admit I tend not to look for formal proofs in a case like this. I tried it for a while, discovered it works and wouldn’t go back.
I challenge anyone – try it for six weeks and see if you would go back afterwards.