Why Does Pair Programming Bring Out the Worst In Management?
Why is it that management seem to view pair programming as the worst engineering practice in the world? Could it be that management have never experienced pair programming, and there in the classic “looking in from the outside” just see two people at a keyboard? Or maybe it’s the furniture police 
How can any of the below be seen to be wrong?
- many mistakes get caught as they are being typed in rather than in QA test or in the field (continuous code reviews);
- the end defect content is statistically lower (continuous code reviews);
- the designs are better and code length shorter (ongoing brainstorming and pair relaying);
- the team solves problems faster (pair relaying);
- the people learn significantly more, about the system and about software development (lineof-sight learning);
- the project ends up with multiple people understanding each piece of the system;
- the people learn to work together and talk more often together, giving better information flow and team dynamics;
- people enjoy their work more.
Advertisement
i think its the last one
Matt you make a good point and I’m happy to hear this. Just last week I was working with a colleague of mine on a very difficult problem (dynamically and programmatically loading javaagents at runtime on demand) and we managed to resolve it in a fraction of the time it would taken us individually. Each of us were standing on the other’s shoulders and each of us were able to leap ten steps ahead of the other alternately. Overall we definitely arrived at the best possible outcome very quickly whilst also having learnt a great deal from one another. Interesting pairing is effectively also multi-tasking which is a myth when working by yourself.
From that experience alone I feel that when there is a clear goal/outcome in mind pair programming can certainly be immensely productive and much more rapid in achieving the set goal. However I get the impression that the reason management don’t like it is because they feel that they are getting half (or less) the value of two people combined by putting them on one task. It also perhaps gives the impression that those participating in the pair programming session are distracted from their normal work.
Ultimately from these points of view it seems to be that pair programming should be formally be made part of the development process and the management aware that it is so. However they should also be reassured that it is not a constant activity but purely goal directed when the task calls for it.
Matt – having run my own business where we had plenty of examples of both ‘leave me alone to solve this really hard problem’ and ‘lets work through this tough problem together’ activity, I couldn’t agree more that pair-programming is a great way to build better software faster. The issue for me is that it isn’t natural for many developers, so how do you foster it as a discipline? I would be reluctant to mandate it (actually, I wouldn’t do that anyway as I’m trying to avoid mandating too much in my latest venture), and I also wonder whether there are some tasks better suited to pair-programming than others. Can you say anything about your experience at Lab49?
(I share Dhruba’s view – traditional management typically only sees cost but that’s why there will always be opportunities for more nimble firms prepared to buck the system.)
Matt, I’m not convinced this is a new feature of development, my teams in earlier lives always pair programmed through problems, early design stages and more. Surely this is just good practice and in a closely knit team that should be constantly peer reviewing, this would naturally occur, and not be identified as an approach that should have management concern. Perhaps the answer is to stop identifying terms for what is essentially just good team work?
To Dhruba’s good point… I would add that the key to instilling this is to drive team work… close teams do this naturally, and for those who work alone don’t make it optional, make it part of your peer review and gradually devs tend to open up and request earlier assistance, especially if they know their own colleague is not going to sign off on it! Not saying its the best way, but a great way to get this to work is to get the code reviewer to fix the defects… amazing how well code reviews then go!