agile and pair programming
March 31st, 2009 by Raymond VelezOne of my favorite topics in agile and iterative development is pair programming.The question is can we make it happen more and do we want to try it more? I’ve typically seen it on the smaller and more isolated projects. It’s a fascinating concept and the research, while minimal that I have found, tend to say two developers get more high-quality work done than one independently.
I also found it interesting that it’s a core tenant of education in some circles today. When my wife was getting her master’s in education, pair learning was one of the approaches she was taught. Often it’s three or four, but two works. All her classrooms are broken into small groups and I guess there’s lots of educational research that backs up the fact that students learn more working in small groups than alone. I’ll ask her for some research links.
I ran across an Distributed Agile post today that dug up some more research backing up pair programming. Here’s what the post had to say
“Pairing is the most powerful tool they’ve ever had. Skills don’t matter as much as collaboration and asking questions. Goal for new hires is to get their partner hired. Airlines pair pilots… Lorie Williams at the University of North Carolina did an experiment and found that the paired team produced 15% less lines of code with much better quality”
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=52988dd9-1f5e-4288-94f8-52bdf40b8334)
Del.icio.us
Digg
Technorati
Furl
reddit
6 Responses to “agile and pair programming”
VVery interesting. In fact, in 2006 I set up a distributed agile model for Atlas (Microsoft Ad & Publishing) that was built on paired-programming principles. A 20 person team split in half in 2 separate locations.
It did take a while for the “buddies” to start collaborating or even understanding what that was meant to do. In the last 2 years this model has seen significant improvements and is an excellent choice for product development.
Add Test-Driven development to the mix and you have a winner.
@Dnsee we have been using pair programming for a long time and I’m not yet convinced of the value of this approach. the problem is always the same: is it faster to have two people on one monitor or is better to have to people and two monitors? And if you are in “emergency mode” (no time, few money, a lot of requirements) this is more and more difficult.
In my opinion the more you are developing your own software, instead of customizing ready and proprietary platforms, the more advantages pair programming will give you.
Another question is, does our budget and resource availability, on projects allow for pair programming. I definitely think it helps in the product development space in improving the quality of the final deliverable
Well, the budget would theoretically improve. The premise is that two developers working in a pair programming approach are more productive than two developers working alone. At least that’s what the studies say:).
Great site and I am really pleased to see you have what I am actually looking for here and this post is exactly what I am interested in. I shall be pleased to become a regular visitor
Having done a few months of pair programming when I worked with ThoughtWorks I can certainly say its an interesting practice.
First off, just like TDD, pairing is skill that can take a long time to master and make productive (i.e. increase output *and* quality).
The psychology of the practice is also interesting. Here are some of the things I found problematic: Difficulty concentrating when you are not \’driving\’; Lack of code ownership which is important for many developers; Lack of ability to say \”I built that\” - Agile is all about the team result not the individual result which is great, but unfortunately many human psyches find it hard to cope without individual responsibilities/pride; Trouble concentrating when someone is looking over your shoulder (If you have performance anxiety you may struggle! :)); Lack of ‘quiet time’ - how to fit in the need for solitude in problem solving. Sometimes you just need some time to get your head around a problem before tackling it with someone else.
Personally I think 100% pair programming is counter productive (and a very hard sell to bean counters).
The way I see it being deployed most effectively in a regular code shop is for occasional use (~20-30%?) e.g. on particularly tricky problems, for knowledge transfer, debugging code etc. For the right scenarios it definately makes sense and should be encouraged.
To use pair programming indiscrimately is a bit like doing unit testing indiscrimately. Ultimately its a cost benefit trade off - most of the benefit is gained by targetting a small critical core. Writing unit tests for your DTOs getters & setters is probably a waste of time, but writing them for a complex business object that is going to form the core of a system that will live for 10 years makes sense