Convincing Developers on the Value of Pair Programming July 1, 2009
Posted by mdenomy in Agile, Extreme Programming (XP), pair programming.add a comment
Something that often comes up when discussing the topic of pair programming is the notion of convincing management of its value. Am I paying twice as much to have two developers to work on a task instead of just one?
My experience with convincing management of the value of agile and XP methods has been if you deliver software on time and with few defects management will accept whatever practices get them those results.
The problem I often face and find much more challenging is how to convince other software developers of the value of pair programming. Getting comfortable with pair programming can be a challenge. The evolutionary nature of software development in an iterative, TDD environment means we don’t have all the answers up front. That can be an uncomfortable feeling. Nobody wants to look like they don’t have a clear vision of where the design is going or be uncertain about the best way to implement it. My advice is to get over it. The other person you are pairing with is in the same boat. When you switch seats and they are at the keyboard, they are going to be leaning on you to see the big picture and help guide the design.
Some people advocate code reviews and feel they can serve the same purpose as pairing. That is true in a sense, but one of the problems I have with code reviews is grasping the subtleties of the design and what trade-offs went into a particular design decision. With pairing you are intimately involved in the design, coding, and testing. You talked out the trade-offs as you went along. The tight feedback loop in pairing also reduces the likelihood of having to make a major refactoring that may come out of a code review. I am not opposed to code reviews, I just think pairing provides a better mechanism for good design and coding practices.
A lot of successful pair programming has to do with the two engineers developing a good working relationship and respecting one another. Talk through alternatives, try different implementations, write good tests, listen to one another, and learn from one another. My pair programming experiences have been some of the most gratifying development experiences in my career.
Pair Programming Follow-Up February 6, 2008
Posted by mdenomy in Agile, Extreme Programming (XP), pair programming.add a comment
In my last post I described some of my early impressions on my first pair programming experience. Still no complaints, although a few additional observations.
I am surprised at the end of the day to find that I am a little mentally drained and I think that is a good thing. The effort that we are putting in is sustainable, but it is also very focused. There is little down time since at any given moment at least one of us is “on” and good progress is being made. Even when we are at a point where we are stuck the ideas are still flowing and we are both mentally engaged in the process.
Given the focus that we both have on the task, I find it beneficial to take breaks from time to time to check email, grab coffee, and even read a few blog posts. It would be a tough pace to maintain continuously and I think the occasional 5-minute break keeps both of us fresh.
We are doing a good job of share time at the keyboard, and I see a real difference in the approach I take depending on whether I am at the keyboard or not. When I am at the keyboard my focus is on the details of programming: variable names, style, and yes…just being able to type with someone looking over my shoulder. When I am not at the keyboard I seem to see the big picture better: are we repeating code, what is the complexity like, is this code easily testable.
I just started reading James Shore’s The Art of Agile Development and I hope to learn more about the mechanics of pair programming and tips/techniques to be more successful at it. Mike and I are pairing well together (I think), but I am also looking forward to pairing with someone else on our next iteration , getting a better understanding of how they work and how we can work together.
Pair Programming February 1, 2008
Posted by mdenomy in Agile, MbUnit, NUnint, pair programming.add a comment
I’ve been doing some pair programming this week and have found the experience to be extremely productive and informative. I am pairing with a guy named Mike, who is someone I have worked with in the past and really enjoying working with. We are in the midst of a fairly significant refactoring effort for a particular component.
Although Mike and I often bounce ideas off each other when we are working individually, I think the quality and flow of ideas is significantly better now that we are pairing. That only makes sense I guess. Even if it is code that you are familiar with, when someone asks you a question while you are working on something else it is difficult to grasp the subtleties of the problem. During this pairing effort we are both intimately familiar with the underlying problems and can quickly comment on strengths and weaknesses of a particular approach. The design is really coming along well and we have been able to address issues regarding complexity, IOC, and enhanced testing.
Speaking of testing, this component has a good suite of tests and that is a real blessing when you are refactoring. I feel a lot more confident after a significant change to see “All tests passed”. I have been using NUnit/MbUnit for about 3 years now and I am trying to remember what programming was like before I had these tools. We are trying to work incrementally and each time we get to a stable point we are checking in the changes.
I have to admit that at times pair programming was tough to get used to. On the first day I found myself saying things like “if you want to go work on XYZ I can run with this for a bit and we can get back together later”. Usually this would happen when we hit a snag and I needed time to think though the problem. I was uncomfortable not writing code in front of someone else, even though when I am working alone I recognize this non-coding time as part of moving forward. Something about not having an immediate answer in front of someone else made me feel very uncomfortable.
There have been a lot of positives to the effort, and so far no negatives. I am sure that some of that is due to that fact that Mike and I work well together and have similar beliefs about software development. That is not to say we have always been in agreement, and indeed have had some spirited discussions. We have come up with a design that is stronger than either of us would have come up with individually. We are pushing each other to develop and maintain good tests, and also to push back with the occasional YAGNI criticism. We are also sharing productivity tips, comments about programming styles, ideas about new tools, blog posts, etc, etc.
One unexpected benefit of this pair programming effort has been that people have been less willing to interrupt us when we are working together. Maybe it is seeing two people working productively and enthusiastically that makes people hesitate before interrupting. There have been interruptions but they are fewer and we have also been more willing to say “let me finish up what we are doing here and I can swing by in 30 minutes”.
I am really looking forward to doing more of this. Based on the quality of the code and tests and our overall productivity I would feel confident defending the use of two developers for one task to management. I would also like to try pairing up with other members of the team. I am sure we will go through some of the same awkward startup moments but I think there is a lot to be learned and shared.
