Pair programming works on the concept of “two heads are better than one.” When doing pair programming, two programmers come together and develop applications in the same workstation.
One of them is the driver, who writes the codes and has more control over the keyboard. The other one is the navigator. He/she is also involved in coding with the driver but puts more focus on the overall aspect of programming.
Now, generally, the driver and navigator switch roles in between the task. Or sometimes, two coders work together to write a piece of code. Now, here the question arises. Is this a good decision?
While pair programming can produce good results since one person is focusing on code while the other person takes an overall approach, switching positions as coders to do pair coding is not a good idea.
Two different coders have different mentalities and approach a problem differently. Plus, their naming systems can be different as well. So, you will need to explain your piece of code to your co-worker. Plus, your co-worker may make some changes to your code that you don’t like. Also, using the same keyboard and mouse can be cumbersome.
The primary problem is that you cannot make two people coordinate to produce a single line of code. There will always be conflicts, which will lead to a waste of time. You cannot just divide the task and scale it.
To make it simpler, let’s assume you hired two people to make you a plate of French fries. When peeling and cutting the potatoes, you can just give one-half of the potatoes to one person and the other half to the second person, and they will produce good results quickly. But when it comes to cooking, you can’t just tell both of them to make their halves and mix them. And even if you tell them to cook one plate of fries together, it will create conflict. In both cases, your French fries will be ruined (and the cooks may end up fighting).
First, a coder arranges and rearranges his/her thoughts before starting to type a piece of code. Then he/she writes the code in an IDE. Then the coder can keep that piece of code or scrap it to find better alternatives. However, if someone constantly looks at the screen when the coder is writing when doing pair coding, and if he/she has to explain her actions every time, the person may feel uncomfortable and exhausted. Plus, the other person may feel left out until they are invited to contribute.
So, the point is that pair programming is not the same as pair coding. Coding is just a part of programming. There are other factors like design, execution, etc., which work together to make up an application.
The problem is that today’s development community is that they don’t want to think about design at all. Once they get the business requirements, they tend to jump directly to coding and put all their focus on coding, expecting that some elegant design will magically come out of it. And even if it does, it will still produce better results if the coding is handled by a single person only.
The thing is, making a design up-front may not make your code better on the first try. So, if one person or a group of persons focuses on creating detailed specifications and designs based on the business requirement, the coder will have a general idea about what to create. And then, a single coder will use his/her skills to create a piece of code based on that design.
This arrangement will not make the perfect application on the first try, but you don’t have to make any major changes. Plus, debugging will become much easier if a single person handles the code.
A reason pair programming is not as popular as it should be is as we tend to design by coding. This approach is not only impractical but unappealing as well.
We can change this habit. We can first come together to design the pseudo-code and free-format diagrams. This is like peeling potatoes and can produce great results when working in pairs. Once you have a well-designed pseudo-code, you can hire two highly paid coders to avoid any form of implementation errors. But still, it is not worth it as it won’t produce the best results.
When building software, there are some requirements to be met. The problem of coding first is that we are not able to make the requirements explicit enough. So, if someone else looks at the code, he/she would have a hard time figuring it out. The situation will get worse if we program in pairs.
Figuring out the requirements, solving ambiguities, and eliminating assumptions can become extremely hard when you just have a source code. Instead, these things should be addressed to the entire team even before we even start coding.
Now, this addressing can be done in pairs. You can even have a group of three or four people. During the design phase, the team will ask questions and find answers to ensure that everyone is on the same page. This is the best time to discuss and define your APIs and the data transfer models that you are going to use in the application since these things fall more on the design category instead of implementation. Here, you can work as a team to create a solid design and pass it to a coder.
That is why you must put all the minds together on the design first.
After you have a good idea about what to build and every serious difference of opinion has been resolved, you can finally move on to coding. Now, the group can part ways and make their versions of the code. After that, they can review each other’s code thoroughly and decide which is the best one to go with. Plus, since you already have the design, you don’t need to spend any time figuring out stuff from the source code.
The advantage of this approach is that you don’t need to hire any separate reviewers to test the quality of the code and suggest changes. Any person who is reviewing this code has been actively involved in the design and writing of the code. So, he/she will understand the code better. This will guarantee better results in this vital review stage.
So, pair coding is different than pair programming. When you code in pairs, it will create a conflict, the coders may feel uncomfortable and left out, and the end result may become a mess. However, programming is more than just writing lines of code. It involves design as well. If multiple people come together to create a solid design, it will produce excellent results during the coding phase.
About the Author
ByteScout Team of Writers
ByteScout has a team of professional writers proficient in different technical topics. We select the best writers to cover interesting and trending topics for our readers. We love developers and we hope our articles help you learn about programming and programmers.
The most prevalent file formats used by developers are CSV and XML. However, there is still a conflict between their utility. So, in this article,...
ByteScout PDF Tools are now connected to Zapier! The functions available in our tools can be automated with other services on the Zapier platform. You...
