Pair programming is a method used in some development teams. The idea is very simple – have two programmers – a ‘pair’, if you will 🙂 – work together on the same code. One writes code while the other observes, and they switch roles every so often.
This is, of course, a complete waste of time. You have two people doing the work of one. Every time a decision has to be made, there’s a debate. Every time one uses coding technique that the other one doesn’t recognize, questions are asked, and the whole process needs to be understood. Everything that one developer writes has to be ratified by the other.
As we said, a complete waste of time. It would be far better to have each developer working alone.
Only it isn’t. Far from it.
Studies have shown that pair programming results in shorter software and better design. Pair programming leads to less bugs, and complete tasks assigned to them in a shorter time than just one developer working alone. Pair programming has the huge advantage of propagating knowledge through the system – what one developer knows, now two know. And if you switch pairs all the time (promiscuous pairing, as it is known), the entire team knows more – which means that if one developer is sick, or leaves the company, he doesn’t take any valuable knowledge that only he knows, with him.
Not only that, but pair programming keeps people honest. They won’t switch to a ‘Facebook’ tab, read personal email or skip required design practices. Also, people are far less likely to interrupt a pair working together, than a single developer looking blankly at his screen.
That’s pair programming for you. More efficient, great advantages, knowledge is passed around, experience is transferred from one to the other, and all in all, it’s a great development technique. Because when two people meet to work, towards a common goal, with a purpose and agenda, good things happen.
So remind me again why you’re calling meetings ‘time wasters’?
About Post Author
