Pair Programming: Practical View

Modelling software development processes are being evolved from decades. In this process of evolution, many models have been obsoleted while few served as stepping stone to models we use even today. If you have a little idea of Agile this article will make more sense to you.

XP(Extreme Programming), FDD(Feature Driven Development), Scrum, AM(Agile Modeling) all these are some applications of Agile methodology that are widely accepted for software development.

Agile or simply ready for change

There are certain required properties on which success of Agile development depends. Let us have a look.

Self Organised

All teams are encouraged to be self organised and react in an organised way whenever there is a change of requirements.

Ready to Reconsider

At any point of time customer can think what is going right and wrong for their product, eventually he will come up with change. Now we must be all ready to reconsider everything right from requirement, reconsider plan and execution. This is only possible for a team who understandswhat working in harmony is?

This is possible for a team who understands each other, communicates well. A team where each of one knows strength of individual member and adapt accordingly and there is no place for individualism.

Now we see, if the team is ready to take any kind of hit and each one of them complements the team there is no place for animosity and competition, all are working towards same goal. They are all jelled together, product synced with devs, devs synced with Testers. Given any change they will be able to react in an organised ways. Similarly developers are always ready to refactor and redesign. Considering all of these things in mind let’s see how pair programming can help. From some of my experiences I will take you through it very informally.

Pair programming

Agile is all about keep what is working for team and drop what is not. For some teams pair programming is a blessing and companies like these integrate it in their process. While many are hesitant. There are many valid reasons also for not considering it at all.

I will not say that pair programming is a must but there are certain projects or features that will benefit from it. So if their team thinks they can adapt to pair programming for certain project and then shift to their traditional approach for the next project. This is totally appreciated in Agile.

Some benefits for pair programming are

Strengths

Every developer has his own strength. One can be good writing quick code while other knows the best practices. In some case some developer have a good hands on understanding user interface and other could have more product knowledge. Hence contributing in a rock solid way.

Taking Pilot Seat

While development there will be situations where expertise of certain kind is required. There, one with a best hand can take a pilot seat and progress. While this Dev with expertise is taking charge other can simply observe and learn as a byproduct. This simply minimise any hiccups. Paired for a considerable period and they will learn new skills from each other.

Resting

Working for long hours is exhausting for developers. But this doesn’t mean it will yield more output. They will need some rest periodically for thought process. But in case of pairing when one is working other will be little relaxed. While one rest, still development continues and while both rest they will be discussing problems.

In the middle of no where

Many client requirement needs a prototype. This might require some research and development. Like suppose being a Java developer you are expected to crack a prototype in Dart.

Of course any body can learn and develop that prototype but when paired together the radius of learning expands drastically. Imagine your partner is stuck and trying hard to achieve while you are already doing some random searches and come up with the solution. So research as you develop totally make sense when paired.

Conflicts in a good ways

When paired, developer often argue over an approach and thus having conflicts in thought process. This will lead to identifying tradoffs of each others’ approach. They try to identify what will happen when we take this approach in xyz cases. Finally the one that is most suitable is selected. But this is only possible if they are good listeners and just don’t brag about their thoughts to be more right. It’s never about right or wrong, its about appropriate and healthy. And when situations change they must gracefully accept each other’s way.

Distribute it when necessary

There will be always be some checklist with a project. Some projects have a core business logic and then integrating code at several places. While central logic can be done in pair other task can be always distributed and achieve in parallel.

Un-pair sometimes

Above were some nice facts that I learned but there is one more things very important. After couple of projects together it is very healthy to either shuffle pairs or just switch back to traditional approach. This enables developers to get some space and not to be too dependent on each other. Next time they will be excited to know when they are paired again. As this next time each of one will have added some more skill set in their bucket.

Conclusion

After some experience I have some beautiful memories and shared some great laughs when realized something stupid has been done. I realized understanding requirement is more easy as there is someone to re-verify. In any difficult situation there are more chances to find a workaround as this other person is going through same challenges. More over ready to rewrite almost anything. While developers are having an upgrade ultimately team is going to benefit from it.