The advantages of pair programming

rafa-alves under CC license

In agile software projects, it goes without saying that the developers work together. Scrum is, after all, based on teamwork. In most cases, however, each programmer works alone in front of their screen. The concept of pair programming is different because it pairs up two programmers who then together work on the same task, taking turns who sits at the keyboard.

Customers unfamiliar with the pair programming idea might think this is some sort of job creation program:

Why should we pay for two developers to work on a task that one programmer could do alone? This would only make sense if it cut development time in half, but that is most certainly not the case.

No, this is indeed not the case. But how does pair programming benefit customers then?

Pair programming: pilot and navigator

The main objective of pair programming is to improve the quality of the code. Pair programming is an agile development method with roots in Xtreme programming but is now used when using other agile frameworks.

You can compare pair programming with driving through an unknown city that has a complex road network. An experienced driver will reach the destination on their own, but they will likely take some wrong turns, make a few extra laps and overlook a traffic sign or two on the way.

It’s better if one person drives while the passenger consults the map. Ideally, the passenger is just as capable and alert a driver as the person at the wheel and can oversee complex traffic situations.

This is where pair programming comes in. (Unfortunately, there are no foolproof navigation systems for software development and software projects). The "driver" – often called a pilot – writes and tests the code. The "passenger" – often called a navigator – monitors the driver’s work, verifies the code is correct, points out potential tricky areas and problems and makes suggestions for improvement. After a few minutes, the pilot and navigator switch roles.

Fewer bugs and fewer additional costs from errors detected too late

The 1-10-100 principle applies in software development. According to this principle, the effort and costs for troubleshooting increase depending on when the error is discovered. Errors detected by the developers while programming can be fixed quickly and with less effort (1). If a tester detects an error in a test system, the effort is significantly greater. They must document the error, forward it to the developer and update the test system after the error is fixed and then repeat the test (factor 10). Errors detected in live systems are even more severe because the live instance must also be updated. Furthermore, there are other consequences such as angry users, sales losses due to unusable features, and of course image loss (factor 100). Fixing errors gets more and more expensive the later the bug is found.

Pair programming uses the four-eyes principle to help avoid, detect and fix more errors while still coding. This way, many bugs are caught early on and never enter test or live systems – a fact that is statistically proven.

Preventing islands of knowledge – for the good of the project.

An experienced developer can be highly productive working alone. However, a single bad decision by this developer can have disastrous consequences. This developer is the only team member who has programmed the module and therefore the only person familiar with the subject matter.

Pair programming helps prevent the problem where individual programmers are the only ones familiar with specific areas of the system. The team does not suddenly face major problems if the developer changes teams, becomes sick or leaves the company on short notice. This is how pair programming prevents risky islands of knowledge and promotes the exchange of knowledge. Projects run more smoothly with fewer losses.

For these reasons, we do not always pair up the same developers; rather we rotate them to ensure that every developer spends some time in front of the screen with each programmer on the team. By always staying in communication with one another and combining their knowledge, teams achieve better results more rapidly than a single developer working on a problem alone.

Improved software by continuously checking the plausibility of ideas

The idea behind pair programming is to identify bad ideas and decisions by conducting ongoing sanity checks, improve and optimize good ideas. This results in better code and ultimately increases overall productivity. From experience, we believe pair programming makes developers more focused and work harder because they are less likely to distract themselves if they work together.

(The result of this, however, is that the developers often find pair programming more tiresome. In practice, we recommend that developers take regular breaks where they split up and not work in pairs for the entire day, especially because there are other tasks for which the four-eyes principle is not necessary or useful).

In any case, sharing knowledge among pairs and rotating across the entire team does indeed result in better software design and shorter (and therefore more maintainable) code. And lastly, pair programming improves the technical skills of the developers involved, which in turn improves the team’s efficiency and the quality of the results.

Conclusion: Effort well spent 

It is worthwhile for customers to understand the potential of the pair programming concept. Pair programming creates an optimal environment for developing the best possible software and ensuring the development team is working as efficiently as possible and significantly reduces additional and repair work in the future.

And the additional expenditure upfront is not as dramatic as one might expect. In comparison with conventional development, the extra expenditure for pair programming is not double, as one might expect, it is only a 15%. This has been verified by Alistair Cockburn and Laurie Williams as part of a controlled study. Further information on the results of these experiments will be provided in a future article.

Your partner for custom software development with Scrum

Are you planning a software project? Do you want to expand an existing system or migrate a software platform? Do you require interfaces between applications within your company? And do you expect high quality at all times?

If so, //SEIBERT/MEDIA is the right partner for you. For us, expandability, performance, scalability, platform independence and testability are what really matter. That's why we create custom, high-end software solutions that can be expanded and modified flexibly in the future. Feel free to contact us with no obligation! You can find more detailed information in our public wiki: Introduction to software development with //SEIBERT/MEDIA.

Additional information

Budget planning in Scrum projects and possible reactions to cost explosions
Reasons why you as customer should test your new software intensively and at an early stage

Diesen Beitrag auf Deutsch lesen.

Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud
Our blog articles reflect the situation at the time of writing and are not updated. It is therefore possible that the contents are outdated and no longer correspond to the latest developments. We do not accept any liability for this.

Leave a Reply