14

I've worked in a few shops where management has passed the idea of pair programming either to me or another manager/developer, and I can't get behind it at all. From a developer stand-point I can't find a reason why moving to this coding style would be beneficial, nor as a manager of a small team have I seen any benefit.

I understand that it helps on basic syntax errors and can be helpful if you need to hash something out, but managers that are out of the programming loop seem to keep seeing it as a way of keeping their designers from going to Facebook or Reddit than as a design tool.

As someone close to the development floor that apparently can't quite understand from a book tossed my way or a wiki page on the subject... from a high level management position, what are the benefits of Pair Programming when dealing with Scrum or Agile environments?

Improve this question
6
  • 2
    I think it's useful in very specific situations. But as a general development model, it's kinda useless.
    – Ryan Kinal
    Sep 28, 2012 at 21:22
  • 4
    It may depend on the software, which could color your view. If you have lots of little widgets and work on different little custom pieces of software every day, it's likely not useful. It becomes extremely worthwhile when you're dealing with a large enterprise system where developers need to account for the cascade across the system made by the functionality they implement. Writing one class that effects data used in over 30 distinct places can generally better be reasoned about by 2 people who will have varying mental processes for it. It's like a monte carlo method for pre-defect finding.
    – Jimmy Hoffa
    Sep 28, 2012 at 21:34
  • @JimmyHoffa So the major thought process is that if we find the bugs before they even make it to acceptance testing we can greatly reduce the time lost on code reviews/testing down the line?
    – Jeff Langemeier
    Sep 28, 2012 at 22:31
  • 3
    @JeffLangemeier It's actually more than that; If you see the flaws in the design of section A1 of subsystem A before A1's even written because of the natural discourse that occurs between two developers in the midst of implementing subsystem A, you're not only saving the time that would be spent fixing section A1, and sections A5 and A7 which are dependent on A1 (or finding bugs in those dependent sections due to the cascade from fixing A1), you're saving the time by not writing that bad section altogether. It reduces test time yes, but it further reduces dev time in this fashion.
    – Jimmy Hoffa
    Sep 28, 2012 at 22:34
  • @MartinWickman This isn't a duplicate. In your linked one they really were looking for Cons, even though the title was asking for Pros and Cons. Also, a more thorough answer of the pros was given in this one; to the point that, it is beneficial to the community to have this one even if it's close to the other.
    – Jeff Langemeier
    Oct 1, 2012 at 20:58

4 Answers 4

Reset to default
25

Partly, it depends on how you are doing pair programming. In some instances, the driver of the pair is writing code, while the second member of the pair is observing and discussing the design and implementation details of the system. Another instance of pair programming involves both people writing code simultaneously - one person is writing the implemented functionality and the other is actively developing and writing test code at the unit and integration level, again discussing the design and implementation details of the system.

Regardless of the type of pair programming, it effectively serves as a continuous code review. You have two people's eyes on the code, watching for errors before they escape into a later system/acceptance testing environment or the field. You also have two people who understand a particular part of the system very well, to serve as a redundancy to minimize your bus factor. Both catching defects early and spreading system knowledge around the team reduces the cost of building a system.

The spreading of knowledge isn't just limited to the technical knowledge of the team, either. Depending on who the pair is, it can allow for information to flow between a more senior member of the company to a new member about other things that transcend the project - coding style, company culture, expectations, and so on. It can also allow someone who is more familiar with a technology or tool to share their knowledge in that technology or tool in a real-world applied setting.

As you mentioned, it also does help keep developers focused and in flow. In addition to flow, many individuals are less likely to interrupt multiple people working on something than a single individual working on something. If you walk by someone's desk and they are working alone, but you need to talk to them, you might knock and talk to them. This is less likely if you see two or more people collaboratively working or having a discussion - you won't interrupt them. Interruptions cost time, and spending more time means higher costs. It's in the best interests of the business to maximize productivity of the employees.

However, there are some challenges that must be overcome to make pair programming viable. Consider things like personality clashes or choosing the pairs to properly distribute the knowledge. There's also consideration of exactly when to rotate pairs. Pair programming done haphazardly probably won't be effective as one that's planned out. Depending on the makeup of your team, it might not be effective to pair people at all.

Improve this answer
7
  • +1 for the great answer. I still strongly dislike the idea, but you present its benefits well.
    – user53019
    Sep 28, 2012 at 21:26
  • I like the cut of your jib sir, this explanation actually makes this feel viable.
    – Jeff Langemeier
    Sep 28, 2012 at 22:28
  • 9
    I prefer a hybrid model where the pairings are more ad hoc based on current needs. Also, there are times when working alone is more efficient and times when working with a partner is better. Being forced into permanent pairs seems arbitrary and inflexible to me.
    – jfrankcarr
    Sep 29, 2012 at 1:53
  • Very good answer. I am also a programmer on an agile team and we do a lot of pairing. At the beginning we were skeptical also, we thought that working alone is the best way to go. Than, at some point in the evolution of the team, we imposed pair programming. NO production code was committed if not pair programmed. This was an artificial enforcement of the pairing concept but it helped a lot the team. Finally, after we all got used to the technique and each-other we changed our stile and we are teaming ad-hoc and mostly when the implementation is more complex or error prone.
    – Patkos Csaba
    Sep 29, 2012 at 9:01
  • @jfrankcarr, nobody even suggested permanent pairs; I'm not sure where you came up with that idea. (Notice that this answer specifically mentioned "when to rotate pairs".) Our team found that it's a really bad idea to keep the same two people pairing with each other for more than a day or two; you start to get in a rut. Some teams rotate every hour and a half (PDF link).
    – Joe White
    Sep 30, 2012 at 21:59
3

  1. Less Errors in the final code (efficiency)
    Not completely replacing code reviews but highly effective for getting things right early on. There is research out there that points in that direction.

  2. Faster completion (effectiveness)
    There is several research pointing this out. When it comes to complex features 2 heads are simply more effective. Experience in Pairing is a must for this.

(note: This is your salespitch for the manager: Financially a sane decision because you get more efficient trough lower number of bugs and more effective by faster completion)

  1. Teaching Juniors
    You can add a junior directly to a more experienced programmer. If you have a group of absolute beginners, it's easy to stick around and let them, as pairs, figure the basics out. Stick around and give advice. The concept is apparently very old and stems from craftsmanship.
Improve this answer
3

Quick Answer: most of the benefits and costs are posted in Wikipedia however, let's look at it from a bitdifferent angle.

I would like to mention specific cases of pair programming benefits that apply to agile/scrum development environment, taken from blog post:

The success or failure of software is dependent on its quality, and Pair Programming directly improves quality in numerous ways. When two developers work together design pattern quality improves as the pair develops short, simple, and easy to maintain code with fewer bugs. Bugs are a major quality concern in software development; with two sets of eyes writing the code, more mistakes are caught, thereby decreasing the cost of development. Bugs found late in the development process are often costly to fix. Finding software defects early prevents and helps deter difficult problems down the road. Complexity often arises in programming, and two minds working to solve a problem together can see more options and draw conclusions more quickly than one.

in Summary:

  • Promotes team communication
  • Promotes efficient application knowledge transfer
  • Promotes accountability on design approach
  • Results in better, easy to maintain code
  • Helps eliminate buggy code in its early stage
  • Increases team productivity since the team members will have undivided attention during coding
  • Improves communication and collaboration skills of the team members
  • Builds camaraderie at workplace
  • Makes work more fun
Improve this answer
2
  • When two developers work together design pattern quality improves -> that phrase does not make sense at all. At least not more sense than When two bakers work together wheat quality improves or When two race drivers work together asphalt quality improves.
    – phresnel
    Nov 26, 2018 at 15:28
  • That is a quote from blog that you may look into. However, my intent was to stress better focus on technical design & quality of code, with some type of accountability in place, as each developer strive to be proud on code that is created.
    – Yusubov
    Apr 29, 2019 at 3:54
2

There are a few benefits for pair programming:

  • The two programmers are able to collaborate on the design together, potentially producing better architecture/code - two pairs of eyes can spot mistakes
  • Institution knowledge is preserved better - if one programmer leaves or is unavailable, the other should be able to continue the work without much loss of productivity
  • It's one way to quickly train new developers - pair them up with an experienced member of the development team and they'll be able to experience the code base from the perspective of a veteran of the team
  • Better discipline - the paired programmers are likely be productive over a longer period of time, since one or the other can take over for bursts of activity. Potentially tedious tasks, like unit testing, might be skipped less frequently than for solo developers.

Wikipedia also has a nice summary of the costs and benefits in the wiki entry.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.