Parallel Pair Programming
Parallel Pair Programming
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
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.
Published at DZone with permission of Mark Needham , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.