Pair Programming Issues

Unlike most of the people writing on Agile, I have only two and a half years of experience in software development. But that’s not the only unlikeness, unlike most of them, who were born in “The waterfall era”, when I was born in software industry, Agile was already quiet famous, and that’s the only software development process that I have worked upon. So, I am completely unbiased towards waterfall, I have just read and heard (from senior colleagues , both praises and slangs )  about it .

I have seen people migrating from different development models in Agile. I have also seen few freshers (like me) being born in Agile era directly. And after a very short interval , almost all of them feel it’s a very comfortable and efficient way of software development. I agree too.

However, when you will read about Agile, re factor and rewrite will accompany it everywhere. Why So?

We all know that change is unavoidable and we must adapt ( so must re factor). But the amount of re factoring done in agile is awful. There has to be some reason behind that and I think its pair programming.

Lets see why I blame the pair programming:

• Generally people don’t think a lot while pair programming as the person who wants to think about the pros and cons will be considered inefficient (as he will slow down the coding speed). So, generally people show fake confidence on the effectiveness of the proposed solution. Some common comments will be (“We will change the code if problem occurs”). The re-factoring tasks generated due to this type of attitude is the outcome of pair programming only as no single person can be held responsible for the mess created.
• One of them suggests solutions very fast, which are always crap, and will always need a reimplementation . His pair has to find the loopholes in the proposed solution in almost no time. If not, he has to go with the proposed solution. (And it’s not necessary that the fastest solution will be the best one).
• Persons having aggressive and inhuman behavior will make their decisions accepted (even if his pair is having a better solution).
  When two persons pair, the entire code flow is neither of them, as two persons can not think exactly same things at same time. So, the outcome is a spaghetti of their thoughts which will need re factoring for sure.

Another goodies of pair programming:

• Pairing is a practice which depends a lot upon human nature. So, if the person you are pairing with is a pain in ass (which many people are). Then trust me, you will end up cursing Agile for this.
• Along with all this fuss, you will always find people who will try to hide their inability to work as a standalone through pairing. Or I will say, that pairing a lot, decreases anyone’s confidence on his capability of working alone.
• Pairing with persons having lots of behavioral problems can lead to utter frustration and irritation which in turn decreases you happiness level -> effectiveness -> productivity.

I feel that Agile is a flexible and strong software development model. But people sometime exploit its flexibility by writing bad (incomplete, unoptimized, inextensible) code. Pair programming removes the accountability from a person, which is exploited pretty easily.

Finding some alternative for pair programming or tweaking it a bit can really help. Like pair only after the code is written once, so that the code can be reviewed (or a better solution can be provided). Because the code will be there in its entirety.

PS:If you still feel pair programming is fun, you have not coded with psychopaths.