Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 19 down vote accepted

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.

share|improve this answer

Quick Answer: most of the benefits and costs are posted in Wikipedia however thus is my interpretation from different 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 technical and application knowledge transfer
  • Results in better design
  • Helps eliminating buggy code early or not introducing it in first place
  • Increases team productivity since the team members will have undivided attention during coding
  • Improves communication and collaboration skills of the team members
  • Makes work more fun
share|improve this answer
  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.
share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.
{"cc_re__cc_re__cc_by_sa_3_0": ["                  <li><a href=\"//area51.stackexchange.com\" title=\"proposing new sites in the Stack Exchange network\">Area 51</a></li>\r\n                        <li><a href=\"//careers.stackoverflow.com\">Stack Overflow Careers</a></li>\r\n                    \r\n                </ol>\r\n            </td>\r\n    </tr>\r\n</table>\r\n                </div>\r\n            </div>\r\n\r\n            <div id=\"copyright\">\r\n                site design / logo &#169; 2015 stack exchange inc; user contributions licensed under <a href=\"http://creativecommons.org/licenses/by-sa/3.0/\" rel=\"license\">cc by-sa 3.0</a> \r\n                with <a href=\"http://blog.stackoverflow.com/2009/06/attribution-required/\" rel=\"license\">attribution required</a>\r\n            </div>\r\n            <div id=\"svnrev\">\r\n                rev 2015.5.1.2550\r\n            </div>\r\n            \r\n        </div>\r\n    </div>\r\n    <noscript>\r\n        <div id=\"noscript-warning\">Programmers Stack Exchange works best with JavaScript enabled<img src=\"http://pixel.quantserve.com/pixel/p-c1rF4kxgLUzNc.gif\" alt=\"\" class=\"dno\"></div>"], "copyright__copyright__copyright": ["ve 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.\n\nWikipedia also has a nice summary of the costs and benefits in the wiki entry.\n\nshare|improve this answer\n\nYour Answer\n\n\u00a0\ndiscard\n\nBy posting your answer, you agree to the privacy policy and terms of service.\n\nNot the answer you're looking for? Browse other questions tagged or ask your own question."]}