As we want to build products which are maintainable, extensible and scalable in the long run. Usually we do this with the help of a team of solo developers. Let’s see how this can be done more efficiently in a better way with developers working as pairs.
Recently I went through a Developer Bootcamp focused on Agile methodologies of Extreme programming. Pair programming was one of the focus of my bootcamp. This bootcamp was like an eye opener for me, so I would like to share a few misconceptions which were cleared in the same.
Before we get into technical stuff of pair programming, I would like to tell you a short story from a real life incident which is analogous to software development.
One fine Saturday, me and two of my friends decided to go on a long drive. I took my bike and my friends started with their car. Since I was on two wheelers I was able to pierce through the city traffic very quickly, but as soon as I got to the outskirts of the city, my progress was struck, because I have to stop and see the navigation map in short intervals and therefore I cant drive myself beyond a certain speed. Whereas my friends were behind me, stuck in the city traffic, but as soon as they crossed the chaos of city traffic their velocity became quite high and sustainable, as one of them drove and the other navigated.
Do you see the difference ? Why my friends overtook me in cars, even though I was able to take a good lead in the beginning?
If you’re wondering how is this related to pair programming, keep reading.
No alt text provided for this image
So basically, the same thing happens in traditional project development. In kick off phase of any project we just allocate head counts and ask them to start working. At first, everything seems to be smooth,We can see new features being released frequently. Remember how I pierced through the city traffic and took lead ?
But as the project progresses and things start getting complex ,few small issues start popping up. Code reviewers starts getting too many code review requests and then it becomes bottle-neck.
What if a person responsible for devops fall sick ? What if I met with an accident ? If something goes wrong (which I hope never to happen) with one of my friends, another can take over. This is called the Bus effect in action.
So to sum up -
Pair programming is an agile software development technique in which two programmers work together at one workstation in order to :
deliver efficient work
write code with fewer bugs
share technical knowledge while developing (thus reducing pain points)
upskills developers interpersonal skills
Now, few misconceptions which I had :
Why should an experienced person waste time ramping up novice ?
Focus is on building up large pool of redundant assets rather than only on delivering features.
It’s like carrying Stepney, which would help you when something goes wrong with the main tire. Reducing Bus effect.
- Some may feel that they are not able to get into focused mode, since they are supposed to talk while thinking/coding. -
They can ask for a time-boxed break to think independently and then come up with data.
It’s like using first gear in steep ascend, where speed is slow but it elevates you. Don’t expect to drive in same speed/gear throughout the journey.
- Some may feel that it takes two asset and double man-hours to accomplish same features
Reality is code review and the refactor cycle time is saved. It’s not exactly double, it’s way less. And at the same time, quality is way beyond the sum of the parts.
Four wheelers takes more space than two wheelers but in long journey two wheelers can’t beat them
No alt text provided for this image
Two wheelers(solo developers) can help in conquering city traffic(starting of big projects). But if we want to go on a comfortable(maintainable), sustainable long(scaleable) journey(product). Four wheelers(pair programming) are go to. It(pair programming) has redundant assets — drivers, tyres, etc (large pool of assets). It(pair programming) has more momentum (one pair can motivate another one). It(pair programming) is fault-tolerant (One pair may catch corner-cases missed by another pair), safer (reduces bus effect)
Still not convinced ? Cool! Checkout this research paper https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF and let’s connect!
Thanks for your time. Let me know your feedbacks.
Top comments (0)