Rest in home for a while now, while enjoying programming by myself alone these days, suddely I recall the unfinished thinking about Pair Programming long time ago.

Pair Programming is the very important part when we carry out Agile in Company. As we know, They discussing the requirements, design and implementation all the time. One person coding and the other one watching and reviewing at the same time. They both know the progress so well, thus they can swith their roles easily. We’ve heard lots of praises for it, but after these year, testing quite many senarios with different people, I’m doubting if it really works?

As my understanding, programming is a kind of handcraft work, Programmer is craftsman. It do require you sucked into yourself, rearching the ZONE. And people are different, they have totally different behavior while programming, Some may like bare foot, some likes standing, some can only concentrete in the rest room, some have to keep on eating … and their way of thinking is widely different too, some fast, some slow, their experience determined the imparity.

So what a hard work to bring two different people together and trying to make an agreement in that situation. The cost is very high!

Not for efficiency

Adding one people bring more complicity, it’s obvious loosing efficiency. So what we want?

Better Result?

Slow is not always bad, some times, Slow is fast.

Two people discussing through the process will help them understanding the problem and making better desging and codes. I think that’s true, but …

• If two juniors, can they bring out best result? no, but better.
• If senior with Junior, does junior able to find problems and provide help? probably not, but better to try.
• If two seniors working together,still it doesn’t mean they can give the best solution, but probably better.

We can see, we do have BETTER result. But does the BETTER result GOOD ENOUGH? It’s really hard to say, it depends. And if you considering the cost of time wasted, is it deserves?

You can’t have all

Making things a lit better will cost more, that’s realistic. So BETTER code and better velocity, you do have to make a desicion.

A frustrating data by our practise is, the codes delivered by pair programming is still not good enough, even in the senarios senior guys joined. And we still have to do final technique code review and QA verification for every story. so the quanlity doesn’t dramatically improved, but we loose velocity. There’s something can lead Pair Programming to fail easily.

Faliure incentive

• Lacking techinque or experience. Two juniors working together can usually see it. Althought they do discuss furiously, the result is still -_-

  probably we can show them another high-efficient learning way.

• Unclear responsibility. Two people working on one thing, it means no owner at all. if there’s one not that self-disciplined, then it’s doomed.
• People have different working clock. Even they can coordinate time, you would see the time lost is huge!

Do it right

• Programer is cat, they like pramming alone, you have to see it
• More people means less efficient, you have to accept the time lost
• If pair programming do make quanlity better, probably means somewhere else goes wrong. You may solve them in a different way to bring back velocity. (Here can expand to another big story.)
• Sharing knowledge and idea is great! that’s should be the only reason for pair programming.
• More than 20% time for Pair Programming is a bad smell
• There’s other practises to improve code quanlity, think hard. Pair Programming is not silver bullet.

Private Programming

At last talk about Private Programming.

Company usually want to make people easily to shift, asking people to use same software, even coding in the same style. We can’t say that’s totally wrong.

But if programmer is craftsman, you do need your own style. You need build your own tools, you have to find your efficient way. For example, choose your Operating System, your keyboard, your desk, your coding font, your ide, your key binding … (it’s another big story too) In a word, make yourself feeling happy while programming is important too!

Homogeneity is good for company but bad for youself. However, they are not totally opposit to eachother. Be smart and find the balance, that will makes everybody profit.