Pair programming is likely to be the most misunderstood of all Agile development techniques. While the practice is known to have been used for decades, it was only made popular in the early 2000’s by the Extreme Programming methodology and has subsequently been met with a great deal of skepticism. In this unconventional style, two software engineers work side by side at the same computer. While one developer, commonly known as “the driver,” writes code, the other, “the navigator,” critiques the work and strategically plans the next steps to be taken in the programming process.
From the casual perspective of an untrained eye, pair programming can easily be misinterpreted as a big waste of time. After all, logic would seem to suggest that two developers engaging in separate tasks would be able to accomplish twice the amount of work. When other less obvious factors are taken into account, however, this argument holds very little water. Through our many years of experience in the industry, Software Planet Group have learned that when used skillfully and for the right assignments, pair programming not only saves time, but also emerges as an invaluable practice to ingeniously generate high-quality code.
Most companies are inclined to launch development with a team of individuals dedicated to isolated tasks, but this can lead to communication issues and a largely chaotic environment. Through pair programming, however, SPG are able to begin work conservatively and later increase the size of teams exponentially without ever having to compromise shared technical knowledge, and consequently work harmony.
We aim to start all our projects with just two developers who in tandem lay the groundwork for the new software architecture. The team are then split into two different pairs, so that each new couple includes at least one individual initially involved in the project. Subsequently, these teams can also be split into two more pairs, so that now four pairs of developers contain at least one person with a shared understanding of the project, and so on if necessary. Because this common knowledge is vital to a project’s success, we switch pairs often to maintain a steady information flow.
For customers, the real benefit of pair programming is in the quality of code achieved by two minds rather than just one. Working with a partner means our developers are able to brainstorm solutions that would usually remain unexplored by lone programmers, allowing our overall system architecture to be greatly improved.
At SPG, pair programming is further strengthened by a test-first approach known as Test-Driven Development (TDD). While every good developer is expected to test his or her code extensively, using TDD, our own programmers invert this process by first writing tests for a very simple piece of functionality that is yet to be implemented. They then write the simplest code possible for the feature to pass the test, and the code is later restructured to meet all requirements. This process saves time — and consequently reduces costs — because our code is less likely to require future bug fixes. Moreover, unit tests are also helpful to developers who join the team as the project progresses, as they erase the need for extensive documentation by allowing programmers to effortlessly grasp new code.
Of course, just as with any other tool, there are many cases when we would prefer not to use pair programming at all. We have learned, for example, that the practice is not efficient when dealing with simple tasks, and is equally unsuitable for developers with little experience working in pairs. This is why we only combine junior developers with experienced software engineers, and never use pair programming in situations deemed inappropriate.
By all accounts, any extreme views unfairly targeting pair programming are nothing but the result of a general lack of understanding of the technique. Because we adeptly employ this practice, Software Planet Group are able to guarantee that our code will be kept simple, testable and robust at all times.
