Partner Programming continues to increase in popularity with software companies, but coders are starting to feel trapped.
As this Wall Street Journal article says, partner programming (or pair programming) – conceived in the 1980s and 1990s – is gaining popularity today, adopted by trendy companies such as Facebook and Square. With Silicon Valley startups raving over its value, it is time to take a closer look at it.
Partner programming involves a pair of coders working together. One “drives” and writes code while the other “navigates,” watching over the partner’s shoulder. The idea is that the navigator is free to find potential mistakes and think about the strategic issues in the code rather than the coding itself. The partners usually switch regularly to keep their minds fresh and allow them to each get “think time.”
Studies through the years have shown that pair programming reduces mistakes, shortens the length of a program, and improves the efficiency of a program. When applied to the right projects, it can reduce total costs by saving money on quality assurance.
Of course, like any development method, it has its shortcomings. As the WSJ article discusses, programming partnerships are like any other relationships – they take time to develop, and not all of them work out.
There’s a more sinister problem: On purpose or not, the result of paired programming is that it creates a kind of prisoner’s dilemma.
A programmer I spoke with who works at a Bay Area startup and wishes to remain anonymous (for pretty obvious reasons) points out the nefarious trap of partner coding: “Since one of us isn’t able to work without the other, we never get to leave the office. I always come in early to make sure I’m not holding my partner up, and neither one of us wants to be the first one to leave at night.”
In other words, one of the reasons paired programming is so efficient is that it forces people to work harder and longer than they might do alone. Whether that’s good depends on your point of view.
Obviously, programmers are salaried, and overtime is not a factor. So anything that keeps programmers in their cubicles longer is good for companies.
On the other hand, burnout is high. “I plan on looking for another job as soon as I can,” the anonymous programmer told me. “It isn’t that I don’t want to work, but I’ve gone from working 10 a.m. to 6 p.m. to working 8 a.m. to 7 p.m. with no jump in pay or opportunity for advancement over any other job.”
If paired programming creates tired, overworked programmers, turnover is sure to follow. And turnover is expensive and harmful to software development companies where a pretty competitive market for top talent already exists.
If you’re thinking about paired programming, consider the work-life balance of your employees. You might think the extra work you get from them is worth it, but you may find that efficiency disappears with high turnover and tired employees. Avoid the partner trap.