Agile 101. Are Two Programmers Better than One?
One of the most interesting aspects of Agile methodologies is the technique of pair programming. This is specifically described in the Extreme Programming (XP) model.
When I mention pair programming for the first time I am usually met something like “Dude you can’t be serious.”. On the surface, this seems counterintuitive. After all, isn’t programming the bastion of the lone wolf? The typical programmer receives design specs and then sits down at the terminal to code, code and code. It does not seem to make sense that one programmer would code and another would look over her shoulder.
I first heard about pair programming at a company I worked at in 2001. At that point it was cutting edge. Now – not so much. Even though it may not be intuitive, the technique has been shown to work. In fact if it did not work, it would not be considered a staple of Agile development. Pair programming has a number of advantages.
- The code is of higher quality. One programmer writes code and the other programmer watches and provides immediate feedback on the overall design and accuracy of the code. Logic errors tend to be caught quickly since the thinking of one programmer is immediately validated by the second.
- More code can be written. Programming in pairs results in more code than if only one person is involved. This is because each person takes turn writing code. In fact, between the two programmers the coding can continue almost non-stop.
- The code is cleaner. A lot of faulty code gets written when a person is fatigued. Pair programming keeps the pair fresh by alternating the roles of the coder and the reviewer. This results in fewer programming defects. Logic and syntax errors can also be caught immediately by the observer.
- Requirements can be validated sooner. If one programmer misinterprets a user story, the second programmer can catch the error immediately.
- Code reviews are not needed. Code reviews allows the code from one programmer to be reviewed by peers. The need for code reviews is eliminated since the code is validated by a peer at the same time it is written.
“Programming” includes the initial code development, testing, and the time for defect correction and rework required to ensure the code is complete and correct. Teams that use pair programming have found that the technique actually results in increasing programming productivity by twofold or more. In other words more then twice as much clean code gets implemented with pair programming as compared with two programmers working independently on different programs.