Reading Time 4 minutes
Agile pairing, takes two to tango!
Once upon a time, I too did not see the benefits of pair programming. I saw work duplication, invasion of privacy and moments of broken concentration. And then something happened, I saw the light!
Why did I suddenly change my mind?
Benefits of Agile Pairing
Let me tell you about my sudden ‘Change of Heart’.
Is Team Work Better?
Why have two developers working on a task when one would get it done faster? This is how I used to think.
I had just joined a new company and was ‘encouraged’ to speak to developers instead of reading introductory documents. Being the new guy, I did not have much choice. I decided to sit down and ask questions.
I thought this would hamper the developer, to my surprise it did not. In fact, anyone that I spoke to or pair programmed with was more than happy to help. Going further, without realizing it at first I was actually introdusing myself to the entire team in a more ‘intimate’ fashion.
I found that I was picking up things a lot quicker, having my worries and doubts resolved quicker but more importantly I felt part of the team on day one! Why have two developers working on a task when one would get it done faster? Not sure how valid this statement was anymore.
Clearly this was taking time, I may have slowed others down. However, was my introduction to the team a really big time impact? I felt it was quicker for me to be a productive part of the team by pairing. I started to see Pair Programming as a way of on-boarding.
Are Code Reviews faster?
My way of programming as always worked. Books, blogs and conferences helped influence how I once programmed. I suddenly found myself speaking to developers and writing code with them, in the process learning a great deal more than books and blogs. This wasn’t entirely surprising but I did find myself asking why I had considered books and blogs a ‘better source of learning’ when compared to a fellow colleague.
Going further, I started to revisit ‘my way of writing code’. I started to write code which felt easier to read, to understand and to manage. The interesting thing about this particular evolution of my coding standards was that it was not imposed on me. In fact I saw the change and a need to ‘upgrade’ my standards.
Did I self improve because I started to talk to others?
Is Velocity impacted?
Going back to when I was not the biggest fan of pair programming, my biggest concern was the impact on team Velocity. This goes back to the notion of one task by one developer vs one task by two developers.
Let’s assume that a developer is stuck, what do they do? The developer can’t ask another developers since everybody is in the ‘one person one task’ mindframe. Most likely if your stuck, you go and get a coffee, take a walk, come back the next day and tackle it again. Failing this you ask someone else.
Now let’s assume a pair were working on the same task. The probability of one developer getting stuck is significantly less since there are two developers. Pair programming in this instance can help to solve problems quicker.
Before I adopted pair programming, I searched online for solutions every time I got stuck. I tended to ask colleagues as a last resort. I guess I did not ask, I thought it would slow down someone else. Not sure why, it toke me some time to realize that being stuck is the same as not adding towards the velocity.
In a very round about way I discovered that pairing actually increased velocity.
Is it worth it?
The big question, is it worth Pair Programming?
Let’s list the possible disadvantages of Pair Programming:
- More man hours to get a task done
- Ego and attitude play a part – this can result in enforced code vs quality code
- The idea of a ‘driver’ and ‘passenger’ does not breed creativity
And now the advantages:
- Better learning
- Higher code quality
- Problems resolved quicker
What do you think, do the advantages outweigh the disadvantages?
I thought so!