Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 534 posts at DZone. You can read more from them at their website. View Full User Profile

Parallel Pair Programming

03.16.2010
| 4346 views |
  • submit to reddit

I've spent a bit of time working with Les recently and it's been quite interesting working out the best way for us to pair together as he's working as a front end developer on the team which means he's best utilised working on the CSS/JavaScript/HTML side of things.

Having said that there are often features which require both front end and backend collaboration and we've been trying to drive these features from the front end through to the backend rather than working on the backend code separately and then working with Les later on to hook it all up to the frontend.

As a result we've found that it seems to be most effective to prototype any backend code that we write while working together such that we just write enough code to allow us to see that everything is hooked up correctly.

Once we're happy that we've got that working correctly then we split up and work side by side, effectively parallel pairing as Vivek Vaid describes it.

At this stage I would focus on driving out the backend code properly with a more test driven approach and Les works on tidying things up from a front end perspective and ensuring that the feature's look and feel is consistent across browsers and doing any other front end related functionality.

The benefit that we've seen from doing this is that we're able to work together on the code where we get the most value from doing so and then split up to work on the other things where we wouldn't add as much value to each other in a pair programming situation.

Since we're working directly together at the beginning of a story we also get the benefit of iterating/talking through the potential approaches that we can take and I've often found that I take a better approach to solving a problem when working with a pair than when working alone.

The thing that we have to be careful about when doing this is ensuring that we're not treading on each other's toes because we are working around the same part of the code base and often on the same files.

This means that there is a bit of merging to do but as we're also sitting next to each other it hasn't proved to be too much of a problem. I think using a source control tool like Git or Mercurial with their merging capabilities would probably make this a non issue.

It seems to me that we're still getting the benefits of pair programming with this approach and I'm more convinced that this might be a useful approach in other situations as well.

References
Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)