One Hour of Pair Programming
I am taking a two day course this week on Unit Testing, Test Driven Development, and Refactoring put on by Net Objectives. Our instructor, Rob Myers, has a fair amount of experience working as an Extreme Programming coach. In an interesting twist to the usual classroom experience, the first thing that he had us do was pair up with another person in the class. After a few minutes of mingling to find a partner who either had complementary knowledge or was someone that you hadn’t worked with before, we moved around so that the newly paired classmates were seated next to each other.
Since I've never pair programmed before, I was anxious to give it a try. But we had to wait almost the whole day to do a programming assignment. Finally, in mid afternoon, we came to an exercise that we got to do together. It was a very simple example which we were to tackle using a Test First approach with NUnit as the test framework.
So it’s pretty tough to gauge a practice after an hour, but my first impression of pair programming was positive. It was fun to work out a simple approach, work through some issues that came up, and ultimately get to see the NUnit green bar for the successful exeuction of the tests for the code that we wrote. My partner did much of the driving and I learned some shortcuts in Visual Studio. We each brought up different ideas when stopped by a problem, and we caught each other’s mistakes before the compiler in many situations.
All in all, the hour flew by. I think it would be interesting to try this for a longer time period to see if we really could be more productive programming in pairs.
Comments
- Anonymous
March 29, 2005
Personally, I prefer pair programming in nearly any situation.
Whereas a single programmer may think he's 'in the zone' and knocking out code as fast as humanly possible, the simple fact is that "two heads are better than one".
The code that either single programmer knocks out on his own may actually be inferior to that which the two programmers discuss and agree on. When you have two people with complementary knowledge, additional options arise from comparing and contrasting their approaches and more options arise.
Management loves to divide up a programming department into separate tasks assigned to single programmers. I think this is a huge mistake.
Pair programming can accomplish programming and design tasks faster and with higher quality than isolated programming.
Go ahead and assign two projects to two programmers. But let them--encourage them to team up on it. You'll get two projects done faster and better than if they were done independently. And both programmers will have intimate knowledge of the functionality built into both projects.
So.... what ws the advantage to islated programming again? As far as I can tell, it's simply that of unconfused management. - Anonymous
March 29, 2005
The comment has been removed - Anonymous
April 01, 2005
The comment has been removed - Anonymous
April 01, 2005
The comment has been removed