Pair programming? Two people staring at one PC screen, using one keyboard and one mouse? Why would companies hire two individuals to work on the same thing?
I have heard many individuals who dislike the idea of the “pair programming” development technique. The fact of the matter is, some of these individuals have not tried it, and therefore they don’t fully understand the benefits of practicing pair programming. There are also those who are not involved in the development cycle but provide negative feedback nonetheless.
Many programmers are groomed as mavericks; in fact, most of us have been trained to work alone and are not willing to share tasks with others. Many of these Lone Ranger programmers have mentioned that they’re “not built” to practice pair programming, as they prefer to code alone and in fact perform better alone. However, I would love to pose them some questions: Does this mean other team members can decipher your code well? Are your team members able to modify your code with ease? And how about integration?
Here are some illustrative scenarios concerning the “solo team” technique:
Case 1
Whenever there is a bug, A will say, “That section was not coded by me, so please ask B.” B will say, “I have no idea and I am busy doing my feature now, so please ask C.” Next C will tell you, “There are no problems with my function; I have no idea why it happened, so please ask the team lead.” The poor team lead will need to check all the problems, line by line, and assign the bug fix to someone he or she feels is capable of solving it.
Case 2
It’s always a nightmare when it comes to integration. Everyone will stand by their code, but when an issue arises, no one has any idea why the integration is unsuccessful. Due to this, some unfortunate team member will have to pull an all-nighter to read and understand code written by someone else and attempt to debug it.
Case 3
“What is this function about? Hmm, oh yeah, I’m the one who did it. But . . . sorry, I forgot what it was all about now.”
“Why copy and paste the same thing over and over again? And why do we need that?”
These questions inevitably come out after a few months.
Unknown codes can be found anywhere, due to unknown copying and pasting, and no one knows what the function is about, but the system will go down without it!
Case 4
Blame games always occur whenever the person who codes the particular function caused a problem and he or she is not around.
Case 5
A is leaving the company, and he is the only person who knows about the search engine. Everyone on the team is ready to panic. Team members will thus have to gain whatever insight A has on the function and will request that A create a document that, truthfully, no one will read. How many people will be able to absorb what A did in the time before he leaves? At the end, it will be the unknown and untouchable code.
Solo mode
Why? When we work alone, we try to do other things at the same time (surf the net, read, attend meetings, design the solution, etc.), but when we pair with a partner, we will both focus on the same task, supporting and encouraging each other.
What are the benefits of using pair programming?
- Software/Code quality
- Ownership
- Satisfaction
- Learning
- Discipline
- Team building
- Communication
- Avoiding hesitation
Lastly, software development is complex; it requires design, security, scalability, performance considerations, best practices, exceptional handling, quality, etc.
Try it! Don’t make assumptions about it!
*
Allan is a software developer at Titansoft. He believes that teamwork and working together will bring more value rather than going solo:”Why need a hero when we have team”
Also seen on : Scrum Alliance
T.8ytes by Titansoft 