There is no peer review activity in Agile Programming. It's embedded into it. When the proponents of the Agile methods started practising it in a bigger way for serious IT projects, there was serious need to doing reviews. Traditionally, the programmers following Agile were all experienced hands and hence there was a little need for doing such reviews. As the projects following Agile started becoming large and complex, two problems started bugging the Scrum Masters and Product Owners a lot:
- There is not enough experienced hands to code any more, since the team size is bigger.
- Complex codes require comprehensive look through the second pair of eyes.
Pair programming principles came very handy this time. In this setup of work, no single developer is assigned a programming task. It's always assigned to a group of two programmers. The technique instructs this pair of programmers to sit in front of a single workstation (computer) and perform the programming corresponding to the assigned task. One programmer is supposed to do the typing of the codes: to be called as the driver. The other programmer is supposed to continue reading the codes being typed and review the correctness of the codes: to be called as the observer. Some books also term the latter person as the navigator. As a result of this setup, the codes are getting reviewed on the point of production.
This technique has been adopted in many IT projects and being implemented successfully, the simple reason being its effectiveness. A traditional software development method mandates review of the program after production, but is mute on the technique. Most often, a developer writes a piece of code, compiles and re-compiles it till it becomes error free (not bug free), and then leaves the program unit for review for an elderly programmer. By the time the reviewer steps in, the program unit may reach to a size of many thousand lines, with the implementation of several requirements. The reviewer on hot seat now has a daunting task of reading through the requirements, and then reading through the programs to make some review comments. There are a many good ways to make such reviews effective, but at large the task is no more a fun affair. This is where pair programming technique clicks. It makes the programming a fun. The programmers interacts continuously between themselves about the codes and implementation and through instantaneous iterations, make the codes better. No more pain and effort for documenting review comments, no more closing the review comments through a loop of comprehensive work flow. Sample this: How many of the traditional code review comments don't start with a statement on the code indentation or comments? The answer is probably "not many". While it's very important to produce properly organized readable codes while programming, quite often the reviewer gets lost within such show-off stuff instead of getting deeper into the question whether any alternative coding would make the implementation better. Pair programming technique allows such review comments to be made right on spot by the observer so that the driver can make the necessary changes right there.
Criticism is not few though. One big question is always put up is about productivity. Deploying two programmers to program on a single workstation perceivably reduces the productivity to half. However, the equation is not that linear. The proponents of pair programming submits two points in this respect:
- Zero Review Effort: Review being embedded into the technique, no separate review activity needs to be planned and managed. This would save some good degree of time and effort. Each organization or project team maintains its own review effort benchmark, and it varies widely. So quantification may be difficult, but everybody agrees that it does not fully substitute a second programmer's time. Here comes the second point, a bit upright and direct.
- Productive Hours: Some of the proponents of this technique openly challenged to walk by the cubicles of the programmers who are nested within their own self for programming. Their revelation was that about half of the population were doing something but coding: checking emails, preparing reports, web browsing, and even blogging like yours truly. According to them, this time would not go waste if two of them staring at the workstation for programming. In a pair programming process, the pair typically gets exhausted after 6 hours of work, simply because the intensity of the focus they need to put into work. On the contrary, according to the proponents, the single programmer programming is not worth more than 4 productive hours sans review.
I admit that this is a questionable argument. Not all organizations foster similar culture, and hence the outcome would largely vary. However, given the quality of the output through pair programming, it may be useful at many times. If not for the entire set of programming tasks, but certainly for the complex and critical sets.
Pair programming also opens up an avenue that the proponents largely ignored: possibility to deploy junior resources. Agile methods don't have enough room for junior programmers, pair programming allows the formation of senior-junior tag team to perform programming and learning to do better coding on the way.
