The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Pair Programming vs. Code Reviews - It's a no Brainer

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Mark Levison

Posts: 877
Nickname: mlevison
Registered: Jan, 2003

Mark Levison an agile software developer who writes Notes from a tool user.
Pair Programming vs. Code Reviews - It's a no Brainer Posted: Dec 14, 2007 11:59 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by Mark Levison.
Original Post: Pair Programming vs. Code Reviews - It's a no Brainer
Feed Title: Notes from a Tool User
Feed URL: http://feeds.feedburner.com/NotesFromAToolUser
Feed Description: Thoughts about photography, software development, reading, food, wine and the world around us.
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Mark Levison
Latest Posts From Notes from a Tool User

Advertisement

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 person understands what’s going on.
  • Fewer bugs – about 15% fewer according to a study by Alistair Cockburn and Laurie Williams (PDF or HTML)

One point which Jeff definitely has right – its hard work. Pairing for eight hours a day is not 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.

If you enjoyed this post, subscribe now to get free updates.

Read: Pair Programming vs. Code Reviews - It's a no Brainer

Topic: My Repositories ala Cairo Previous Topic   Next Topic Topic: Tweets and Points

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use