Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Pair Programming Is A Good Software Development Practice

Category : Agile

Agile is not only about the ‘process’ we follow to build software products. Agility is not just achieved by following a method. Agile is also about the behavior we show while creating software products. But agile is certainly also about the software craftsmanship we show in building software products.

Good software engineering practices help development people build better software, faster. It makes sure they can spend proportionally more time of a sprint on the complex, creative work of designing, creating, testing and documenting the great piece of working software, than they have to do on manual, repetitive tasks.

Unfortunately, too often people and organizations adopt Scrum hoping it to magically solve all problems. Fortunately, Scrum shows them their problems very clearly; opening up the opportunity of addressing them. A lack of good engineering practices (and the absence of tools, platforms, organizational support and automation) is an often encountered revelation when adopting Scrum. Yet, although Scrum doesn’t prescribe specific engineering practices, Scrum does state to have them. Scrum does fully support and promote the 9th agile principle, saying “Continuous attention to technical excellence and good design enhances agility”. And eXtreme Programming is a perfect fit to fill in the demand by Scrum to have good engineering standards. In my experience the combination of Scrum and eXtreme Programming has even shown to be an unbeatable combination.

From the eXtreme Programming set of practices I still promote pair programming strongly, although it seems that over time the exotic feel to it seems not to have vanished.

Let me start by saying that pair programming is about quality in the first place. It’s certainly not about the opportunity to always work with one's best friend. And pair programming is also not about 2 people writing the same code. The success of pair programming, in my experience, lies in the roles and the rotation of pairs.

Rotation and Roles

A Sprint Backlog is composed of the forecasted functionality, i.e. the selected Product Backlog items, and their decomposition in development work. Any person from the Development Team can select tasks, but in our application of pair programming we ask team members to take the ‘lead’ in a PBI, often expressed as User Stories, another technique from eXtreme Programming. The lead commits to taking care of the full story. At the start of the day the pairs are formed, holding that the leads look for the right ‘partner’ to work with them on the development work for the story that lies right ahead of them. After lunch the pairs are reformed. The lead once again looks for the right ‘partner’ to work with during the second half of the day. That’s the first set of roles, i.e. lead-partner, and the rotation, i.e. every half day. The rotation has proven quite essential because it gives team members the opportunity to get the best possible help for any given problem every half day.

During the half day however that a pair works together, they take up a second set of roles. There is always one person holding the keyboard and mouse, the ‘driver’. And the second person, the ‘navigator’, looks over the driver as he/she writes the code. The driver can focus on the code being written, while the navigator minds respect for the overall direction and design. And within the half day that this pair has, these roles are switched frequently. The control over mouse and screen frequently goes from the one to the other, and back. It depends on the specific code being written, whether either of them has done this already before, whether someone has a great idea, etc.

We even encourage people with functional testing skills to join the pairs regularly. It helps people writing better and more complete functional tests, up to the level of creating automated GUI tests, e.g. with tools like Selenium, and including those tests in a test-driven approach and in the continuous integration loops. After all, it is much more fun and respectful to maintain test sets for automated execution over repeating such tests over and over again in a manual way; at all levels: technical, functional, integration, regression, performance.

The separation of driver and navigator is quite essential. It allows activities that a single programmer would do in a serial way anyhow to be performed instantaneously, i.e. in a parallel way (write code, compile, sit back and check, read again, verify coding standards, check naming conventions, consider the design). The person minding the road, writing code, gets immediate feedback, even while the writing is happening, by the navigator who is minding the overview, the overall direction.

And you might as well not complicate your way of working by having to decide when to or not to pair program, in what areas, on what type of work, etc. Just do it all the time. If simpler work pops up which is too easy for 2 people to collaborate over, let the ‘partner’ do something else. That may be some research, a little spike, a break.

The cost of pair programming

The navigator in real time checks the code being written, on standards, optimal solution, duplicate or re-use of code (Has something like that has already been created elsewhere in the system?), naming, etc. These are tasks that a single programmer will also do, on top of merely writing code. It is why pair programming has no higher cost than single programming. Because no more activities than a single programmer would do are being performed. But instead of those activities being done in a serial way, they are now being performed in a parallel way.

And time-consuming code reviews can be deleted from the Definition of Done. And the nasty effects of rework from such reviews, delays, unpredictable efforts, ... are prevented. Waste is prevented.

A little example

Suppose a task estimated at 10 hours performed by a single programmer actually takes 10 hours (to the extent that this can be predicted). The same task performed by a pair takes 5 hours to get finished, but as this time is consumed by 2 people the total cost remains the same. Early studies on pair programming though indicated an increase of the cost with 10%, holding that in my example a task of 10 hours performed by a pair would take 11 hours. To be clear, it is not my experience. In estimating projects or development work we have never raised the budget just because we did pair programming.

Mind however simplistic thoughts over the time gains. It is not like a total volume of work is suddenly ready in half of the time. Obviously on a certain volume of work, the elapse time tends to be the same. If 4 tasks of 10 hours need to be performed by 4 single programmers it will lead to an elapse time of 10 hours, and a total cost of 40 hours. Get the same tasks done by 2 pairs (still 4 people) and they will take the same time, each pair performing 2 tasks. Elapse time is still 10 hours, and total budget is 40 hours.

Quality (and other effects)

Obviously, pair programming results in a lot of communication, makes the room look like a madhouse (when observed from the outside). This is good. This shows the high energy levels, it is not chaos.

As an organization, pair programming should be promoted for reasons of quality first. Early studies found a decrease in defects and rework with 60% and more. So, even if initial budget would be +10%, which I defy, the decrease of rework alone makes it more than worthwhile, from a total cost perspective.

Pairs also produce less lines of code to get the same functionality to work. They create lighter applications with lighter architectures that are easier to maintain, require less server capacity and thus lower the TCO.

A great additional advantage of pair programming is knowledge sharing. By the pair-based collaboration people get insights in other skills, work on other layers of the application, different modules of the system. It allows not having to waste time on getting new team members up and running. They just join the pairs. We even encourage new team members to take the ‘lead’ over a story as soon as possible (and never longer than one week after joining the team). Because it is the best and fastest way to get introduced in all aspects of the software product and be assured of the assistance of the best placed partner, every half day.

In short, Pair Programming should be part of a software engineer's normal daily practice.

About the author


Leave a comment

Your email address will not be published. Required fields are marked *.