Pair Programming

One of the lamest approaches to come out of software engineering in agile methodology is pair programming. It does not work on all occasions and is really a very unperceptive way to be productive in development. Most developers want a sense of autonomy, freedom, personal space, and exploratory approach to their development work. Not be constrained by process and by someone constantly over their shoulder feeding them nonsense. Pair programming can work when it is flexible within co-located desks. But, if two people are physically sitting next to each other it just becomes one really long and unproductive exercise. "Why do you want to do it this way why not that way" - if a senior developer keeps hearing that in their daily work day it is bound to drive them insane. Pair programming can work wonders on a complex piece of legacy code where there is virtually no tests and one needs to do a major service migration. In that respect, it means pairing with someone who either does know the legacy code or someone who can help in process of identifying problematic story cases. It may in that respect also lend towards productivity as one writes out a test case while another is doing the implementation or documentation. It may even help during training of a junior developer. But, really pair programming on a daily work day can be a very droning and frustrating process. For developers, that like to research and investigate new approaches as they go through their every day development, it does not really lend well to pair programming. One cannot test everything before deploying to production. There are always unknowns in a production environment for any number of things to go wrong. Agile approach is meant to work precisely for the reason of making a team agile - quickness, lightness, ease of movement, and nimble. Generally, a mixture of Lean and light weight Scrum use can work in that regard. It seems that many agile development environments have architects and managers that do not quite trust the abilities of their developers for which they start adding more pairing, excessive code reviews, and processes to make sure everything is checked over before it is delivered for deployment to production. Relying too much or adding way too many process-driven approaches into a development team defeats the whole objective of agility that pretty much manoeuvers a team back into the waterfall or seemingly unproductive iterative model. In summary, pair programming is an extreme practice which is not a necessity for teamwork nor for agile software development. In fact, it is most appropriate for those developers that require excessive amount of hand holding or the only way that they actually learn things in their line of work.

Dilbert Jokes on Extreme Programming