Apps

Use paired programming to increase efficiency and reduce bugs

Justin James discusses two ways to use paired programming and offers tips on what you should consider in terms of work setup and skill levels for this exercise.

Years ago, I was introduced to the concept of Extreme Programming (XP). One feature of XP is that programmers typically work in pairs or very closely together on code reviews. At the time, I thought this was mostly foolish. Sure, code reviews are helpful, but if the programmers are so good, why do they need to work together like this? Isn't it a waste of resources? Won't they be half as productive as they are separately? Over the years, my attitude has shifted, and while I haven't embraced XP as a full-time methodology, I think there is tremendous value in paired programming.

When I've used paired programming, it falls under two main categories. The first is when two people truly are programming together as a team; they will sit at the same desk or share a larger room and collaborate. One will "drive" the work, and the other will do it. The beauty of this approach is that both programmers check the work at the same time, and they will come up with innovative solutions to problems. Often what you see is that one person will have knowledge or information that the other doesn't, and that information gets shared during this exercise. It is also a great way for a more experienced developer to show a less experienced developer new tricks.

To work like this, you need the right workspace. There should be enough physical room for two people to sit together comfortably. At my office, all of us have 6' x 8' cubicles, which is very large for cubicles and provides ample room to sit together. Even better, we have a conference room with a large table and a projector. Another critical component is the ability to talk to each other. Too many offices are set up in a way that talking will be a big distraction to others. While our floor plan is a bit open, we all have headphones to tune out outside noises and when people work in the conference room (it is not a good room for keeping noise in). When we moved into this space, we knew from the beginning that we wanted to make paired programming happen whenever needed, and it has worked out very well for us with this setup. Sometimes the programmers will even be in different offices; GoToMeeting and good headsets for the phone call (I'm partial to the Jabra GN9350 series) lets us work for hours as a team without interruption.

The other way I use paired programming is in deep, intensive code reviews. In these situations, the code is already written, but the person who wrote it walks someone else through it. The conditions are the same as when the work is being done together. This is great for finding bugs in code and verifying that what was done made sense. The advantage of working directly together is that it takes a lot less time from the other person. The disadvantage is that any mistakes that are made are found later on, and fixing them is more costly in terms of wasted time.

When using paired programming, you need the right people. Putting two people together who do not know what they are doing will not yield very good results. Putting a really junior person together with a very senior person will likely not be of much use either; at best, it will be a hands-on training session. While knowledge sharing is an expected and desired outcome of paired programming, you do not want to have a net loss of productivity. However, when you have different experience levels or areas of experience, it will act as a productivity multiplier, not just during the session but going forward as well.

Overall, my experiences with paired programming have been very helpful for my team and me. If you have not tried paired programming, I highly recommend it.

J.Ja

Also read on TechRepublic: Is 'pair programming' in your future? and Poll: How do you collaborate with other developers?

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

About

Justin James is the Lead Architect for Conigent.

13 comments
cajonaitis
cajonaitis

The main problem with paired programming is selecting the pairs. This works when the pair is roughly of the same skill set. I have worked in companies that tried it and that is the prime criteria. The other is of course is that each member of the pair will accept the comments of the other member.

ctaylor
ctaylor

After working solo for years, I was told to collaborate with a colleage in a different office to ensure sufficient knowledge transfer to ensure a more solid continuity of operations plan. The systems I work with are significantly different than all the other systems used within our enterprise and were understood by no one except myself. The level of knowledge and manual interventions required to keep them operational without sufficient funding available to bring hardware into compliance with the vendor's minimum requirements was well beyond what manuals and typical maintenance and support contracts would cover. These circumstances inspired management to find someoen who could serve as my backup. Unfortunately this meant that my backup was coming in from the cold and needed to have everything taught to them from scratch. My backup was also physically located in a different office. What started out as 12-plus month knowledge transfer assignment eventually evolved into paired programmiing using shared desktop software. Working together without being in the same physical space requires a slighly different kind of mindset towards collaboration due to the lack of non-verbal queues and body language I had relied upon to understand whether my colleage truly understood what I was saying. What I will add is that paired programming is very dependent upon mutual trust. With trust and openness it can work great. Thanks for providing a name for this kind of approach.

Slayer_
Slayer_

This just isn't working for me.

kenzo
kenzo

[[I've never seen an externally imposed standard that worked.]] Hmm, every time I plug a power cord into the wall, I see an externally imposed standard that works pretty well. :) And I think that is a useful analogy. Everyone knows that standard is not perfect. Everyone also realizes we are way, way, better off than if each device manufacturer created their own non-standard plug (if they ever even bother to think about it)... However, why should programmers defer to a standard if no one insists? Re-inventing the wheel is great fun and pays the bills...

Tony Hopkinson
Tony Hopkinson

it can be extremely effective. The two major road blocks to getting it off the ground aside from picking the wrong work or the wrong pair. Are some developers are loaners, they just won't or can't articulate in a pair. That's not just a wrong pairing. The bigger one though is management, despite talking about it a lot and enumerating all the benefits, because we haven't done much or even any, we have no institutional experience in estimating the impact. So pair development doubles the required resource and you were strapped for them anyway.. Biggest tip though is let your people works out the pairs. Once they've got used to doing it then they might be able to overcome the issues they have working with an other developer, or identify where their particular mix of strengths and weaknesses is more efficient. One guy I worked with we were great on design and coding, but our approaches to debugging were poles apart. So TDD and a new piece of functionality, no problem. Put us both on a vicious bug in legacy software, blood on the carpet. You can't impose pairs.

minstrelmike
minstrelmike

I work in a small shop with 3 developers and a few other support people. We only have one system (200 tables and lots of forms) with 2600 users. Used to have a 4th 'developer' who really couldn't code but wanted to talk about standards. First thing he wanted us to approve before we started redesigning the system onto the web from client server was an 8 page list of approved abbreviations. We ignored him and he finally left. When the system first got going, each of the 3 of us wrote in our own unique style and had forms that looked different. But we did not want standards at all. We wanted users to work with what we had and us to work with what we had and we'd gradually get the forms looking all the same based on actual testing, use, and need. And that is what happened eventually. But what else happened was that most of our source code ended up looking exactly the same also. Almost standardized. As each of us would update someone else's code or copy their version of a form, we'd look at their stuff and steal the good ideas and rewrite the bad ones. It takes the right kind of people. I'm also a writer of fiction and essays and many of the writers fiercely defend their writing instead of accepting suggestions. Programmers whose egos depend on their initial code-writing skills are difficult in almost every facet of development, regardless whether it is Agile or Waterfall.

HighTechAngel
HighTechAngel

I practiced it and I think that it's very important to have the right partner, otherwise it may become beneficial for one but wasteful or harmful for the other. Last time I did it, my fellow programmer was much younger than me but he had experience in some areas I didn't and vice versa, so it was really fruitful for both of us.

kenzo
kenzo

Like almost everything else we do in this industry, this technique will rarely succeed unless the practitioners are given specific training in how to do it effectively. Too many organizations have cultures where any ciriticism or suggestion for change of another's work is perceived as a threat to the code author's position in the organization. Admittedly this happens mostly with junior programmers, but it does happen with seniors also. The work culture of the organization has to be developed to support this type of collaboration- and very few are. Also, defined coding standards are neccessary for reviews to be useful. Even among seniors there is rarely agreement on what constitutes best practices, or internal standards. So if they are not docoumented and defined before reviews, there is a lot of time and effort spent on "re-arguing" the same practices over and over again. This problem is an order of magnitude worse when working with juniors... Individual practitioners can rarely overcome fundamental organizational/cultural weaknesses - and these impediments are the rule, not the exception, in our industry's work places.

joeller
joeller

In my experience, another pair of eyes is always beneficial. I have never worked in an area that formalized paired programming. However, when working within a group on different parts of a web app, it was always most beneficial to have someone else around to bounce ideas off of. Something that might seem simple straight-forward and clear as a bell can be shown to be difficult, and complex when look at from someone else's perspective. In addition, programmers make the worse testers of their own product. They know want they want to accomplish and end up testing the app gear towards that goal. Someone else may end up doing something that the programmer never considered that anyone would do in a million years and causing the app to fail because of it. In a small shop like ours with no professional testers, no VS team system and no test projects, it is very important that a means be devised to get an different perspective on the work. Having other programmers step through your code can be very helpful is accounting for those things you've overlooked.

dariomac
dariomac

Hi, I'm agree with most of what you have said. But, when you said "pair programming in deep, intensive code review." I think that this should be re-written using the right name for that technique. Carl Wiegers defines this technique as "peer deskcheck" when only one reviewer is involved. I'm working in my master thesis and one of the main problems for the usage and adoption of reviews are related with the terms used to call each kind of review. Remember that this terms are related with the formality of the technique, so the correct identification of each one is important to choose wisely wich is the best technique for every scenario.

Tony Hopkinson
Tony Hopkinson

are neither consumers nor vendors. They are electricians... Get buy in. Make it a living document, let the programmers own it, you'll get a standard. It will be a working one, and it will make the code more comprehensible and therefore more maintainable one than any set of back seat coders could come up with. It will be more useful than something that I would come up with. Your biggest issue will be stopping them rewriting code where there's no immediate commercial reason to go that far. If I write non-standard code, my peers insist I correct it and vice versa, Internally imposed standard is not no standard. Now we can have a good debate about what the standard should be, but if you find a developer, who doesn't want one, sack them for extreme incompetence.

Tony Hopkinson
Tony Hopkinson

But we've found a few things to help the process along. Peer reviews is one, using code quality tools is another. Our first peer on .net code is FxCop for instance. I've never seen an externally imposed standard that worked. I'm a big believer in them in them but to say my standard is the only right one and impose it, would make me incompetent and a hypocrite. The standard after all, is there to make the code more comprehensible, not more standard...

Tony Hopkinson
Tony Hopkinson

the spirit of the thing, rather than the nitty-gritty. All too often a set of standards imposed by committee or worse still not by the developers, starts imposing crap like number of spaces to indent, Egyptian bracketing, some moronic Hungarian naming convention. One previous arse misread cyclometric complexity and imposed a standard where there could only be one return statement in a function. So they stuck everything in an infinite loop and used break to get out of it. We have enough problems without garbage like that. The real point of pair development or peer review is to have more than one perspective and more than one person who understands the code. Do that and a living standard evolves, do it the other way and all you end up with is contention over trivia and the letter of the law. Two people who don't understand the code, and a third one who like the indenting style... That's not counting the cost of say re-factoring long lived legacy code to meet a standard.... Pair programming is not one way knowledge dissemination, it's two way. Peer review is not someone criticising your code, it's some one helping you make it more comprehensible. When another developer doesn't understand why I did it this way or called it that. Neither of us are necessarily wrong. In general if their name makes sense, I'll just change mine, now two of us have a glimmer about what it means, which should be the real point of the exercise. Sell it to management as reducing bugs, imposing a standard is fine, don't sell it to your people like that though. You are saying they are non-standard that their code isn't comprehensible, that it's full of bugs and they need help to do the job right. It might be true, you aren't going to get a lot of buy in though. They'll go straight on the defensive, see their peers as threats and the entire exercise will fail miserably.

Editor's Picks