It might seem easy to do a pair programming with another developer. You do the code while he checks, or conversely. And everything theoretically should be a smooth sailing. But in real life it’s topsy-turvy. Why? You obviously have to read about pair programming risks before you start.
In his original article, Martin T. Varga touching underestimated field — the interaction, the cooperation and the teamwork which can dramatically influence the result of the work.
We will extract some important moments for you.
To begin with, we’ll remind you about local and remote pair programming when Driver and so-called Navigator work on the same workstation nearby or remote. In the case of the second option a decent internet connection, headset and any screen sharing software should be provided.
And here the risks:
- High budget. As more programmers work together, less they can share between each other. They’re no longer can affect pair programming with useful knowledge that one can not provide working alone. Like, in the beginning, it’s usually common for one knows less than the other, but the other is more proficient and skilled. So together they are more productive. But when they work together for a long time they educate each other and become more or less independent. So instead of paying to one programmer, you pay to both and it affects the project’s cost.
- Limited innovation and experimenting ability. When you do pair programming you don’t really tend to search for the new approach and check some new stuff in the community. Of course, pair programming does your code safer and more reliable. But at the same time, who knows, maybe while you were coding, someone far away invented new revolutionary great and simple variant? So, individuals are more likely to produce something original.
- Lack of discipline. It often happens that pair is not about to switch (from Driver to Navigator and reverse) for a long time. This factor plays a great role in the clearness and reliability of the code. If the pair will not switch pair programming won’t work. A great solution might be provided by equipping with two mirrored screens and sometimes even two keyboards and a mouse for each developer.
- Wrong pairs. Despite that any task can be done with pair programming, not every programmer is suitable for this. And not all the team members can properly work together. There are many factors should be taken to account for the team leader to pair the developers in a right way. Otherwise, it is not going to fly.
Here we also can take a look on the senior-junior pair. It might be good for junior, he will speed-up his proficiency. But it might be somewhat costly. And from the other point of view, if the junior developer will always rely on his more experienced partner, he will not increase his knowledge and wouldn’t become an independent mature programmer.
- Measuring metrics. Before considering to use pair programming company has to measure its performance. Apart from the number of revealed and fixed bugs, there are more complex things to appear when you do pair programming. It can raise your company productivity, but at the same time can lower productivity of your programmers. Especially on the project where one programmer is enough. Try to think globally: try to measure team velocity, team satisfaction and customer satisfaction before and after pair programming implementation. It can help to understand if it’s worth it.
Before using a pair programming you need to consider all the risks we wrote above. If they will not appear in your team, pair programming can bring you a lot of benefits.