“We have trained, hired, and rewarded people to be cowboys. But it’s pit crews that we need,” saidAtul Gawande — a surgeon and Harvard professor who writes for The New Yorker in his copious spare time — in a recent TED talk. He was talking about doctors, but what tech profession might fit that description as well? Yes, that’s right. You there, huddled over the IDEs on your MacBook Pros. Step forward, software developers.
Coding has always been seen as lone-ranger work; witness the opening scene in The Social Network. Despite managers’ dreams of programmers as fungible units, it’s nearly universally accepted that a great developer is ten times as productive as a mediocre one, and/or that a small team of the software equivalent of the Special Forces can code rings around an army of hundreds of grunts. The flip side is that one cowboy coder’s bad decisions can cripple you — maybe immediately, or maybe next year, when you suddenly discover that your organization has quietly racked up so much technical debt that it has become the software equivalent of Greece.
There are various ways to try to mitigate this risk. One of the more extreme calls for all development to be performed by pairs of programmers: two coders at one keyboard, at all times, with almost no exceptions. The idea (to oversimplify a bit) is that a second mind will sanity-check every bad idea and support every good one, so you — counterintuitively — wind up with higher per-programmer productivity. Legendary development shops like San Francisco’s Pivotal Labs and Toronto’s Xtreme Labs(1) have adopted a 100 percent pair programming mindset, with considerable success.
Great! Problem solved, right?
…Not so fast.
“Research strongly suggests that people are more creative when they enjoy privacy and freedom from interruption … What distinguished programmers at the top-performing companies wasn’t greater experience or better pay. It was how much privacy, personal workspace and freedom from interruption they enjoyed,” says a New York Times article castigating “the new groupthink.” It also quotes Steve Wozniak:
Solitude seems to be essential for creativity: but paired programmers have no on-the-job solitude, ever. Does that matter? After all, it’s “just programming,” right? It’s not an art form. It’s barely even a craft. It’s certainly not creative. Just ask anyone who isn’t very good at it.
Sorry. No. I’ve been writing code for twenty years, and I’ve had half-a-dozen novels published, and I can assure you that there are far more similarities between those two fields than most people realize. In fact, I use the same analogy for both: carpentry. All three are crafts wherein considerable mechanical skill is required before you can add creative flourishes — but that creativity is essential to the end quality of what you’re building.
I’m not saying programming ever rises to an art. There are no software equivalents of Atwood or Marquez or McCarthy out there. But there are many programmers who have done extraordinary work on their own: Marco Arment of Instapaper, Gabriel Weinberg of DuckDuckGo, Notch of Minecraft. Would they really have benefited from pair programming?
…Maybe.
A recent Jonah Lehrer New Yorker piece reveals: “Decades of research have consistently shown that brainstorming groups think of far fewer ideas than the same number of people who work alone and later pool their ideas.” Aha! Further proof that working alone is the answer, right? But it goes on to mention something more interesting and more subtle:
No, no, hell no. The true answer is that there is no one answer; that what works best is a dynamic combination of solitary, pair, and group work, depending on the context, using your best judgement. Paired programming definitely has its place. (Betteridge’s Law strikes again!) In some cases that place may even be “much of most days.” But insisting on 100 percent pairing is mindless dogma, and like all mindless dogma, ultimately counterproductive.
My own preference is a development environment where every feature/module/story has two programmers assigned to it, one “primary” and one “secondary.” (Terminology shamelessly stolen from Homicide/The Wire.) Each developer is primary on one feature and secondary on another. They pair-program from time to time, especially in the beginning, but in general the primary does most of the work, while the secondary spends an hour or two each day sanity-checking the primary’s code and building bite-sized subsections.
Alas, I’ve only worked like this a couple of times in all my decades of development. Those have been the most productive projects I’ve ever worked on…but that’s an extremely small sample size. Further research, as they always say, is needed. In the interim, I’ll leave you with one last quote from that Hacker News discussion:
(1)Disclosure/disclaimer; I did a few months of contract work at Xtreme early last year.
Source:http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/
Coding has always been seen as lone-ranger work; witness the opening scene in The Social Network. Despite managers’ dreams of programmers as fungible units, it’s nearly universally accepted that a great developer is ten times as productive as a mediocre one, and/or that a small team of the software equivalent of the Special Forces can code rings around an army of hundreds of grunts. The flip side is that one cowboy coder’s bad decisions can cripple you — maybe immediately, or maybe next year, when you suddenly discover that your organization has quietly racked up so much technical debt that it has become the software equivalent of Greece.
There are various ways to try to mitigate this risk. One of the more extreme calls for all development to be performed by pairs of programmers: two coders at one keyboard, at all times, with almost no exceptions. The idea (to oversimplify a bit) is that a second mind will sanity-check every bad idea and support every good one, so you — counterintuitively — wind up with higher per-programmer productivity. Legendary development shops like San Francisco’s Pivotal Labs and Toronto’s Xtreme Labs(1) have adopted a 100 percent pair programming mindset, with considerable success.
Great! Problem solved, right?
…Not so fast.
“Research strongly suggests that people are more creative when they enjoy privacy and freedom from interruption … What distinguished programmers at the top-performing companies wasn’t greater experience or better pay. It was how much privacy, personal workspace and freedom from interruption they enjoyed,” says a New York Times article castigating “the new groupthink.” It also quotes Steve Wozniak:
“Work alone… Not on a committee. Not on a team.”Open-plan offices, in particular, seem an impressively terrible idea. “Open plan layouts create massive distraction, damaging productivity,” according to a recent analysis by the U.K.’s Channel 4. See also the related Hacker News commentary, which includes gems like “Most modern office layouts seem to be designed to screw with people’s fight or flight instincts all day,” and “I’m a quiet type, and I often need time alone to think and write code and documentation. The ‘rah rah’ social types railroaded us … I am becoming bitter and resentful.”
Solitude seems to be essential for creativity: but paired programmers have no on-the-job solitude, ever. Does that matter? After all, it’s “just programming,” right? It’s not an art form. It’s barely even a craft. It’s certainly not creative. Just ask anyone who isn’t very good at it.
Sorry. No. I’ve been writing code for twenty years, and I’ve had half-a-dozen novels published, and I can assure you that there are far more similarities between those two fields than most people realize. In fact, I use the same analogy for both: carpentry. All three are crafts wherein considerable mechanical skill is required before you can add creative flourishes — but that creativity is essential to the end quality of what you’re building.
I’m not saying programming ever rises to an art. There are no software equivalents of Atwood or Marquez or McCarthy out there. But there are many programmers who have done extraordinary work on their own: Marco Arment of Instapaper, Gabriel Weinberg of DuckDuckGo, Notch of Minecraft. Would they really have benefited from pair programming?
…Maybe.
A recent Jonah Lehrer New Yorker piece reveals: “Decades of research have consistently shown that brainstorming groups think of far fewer ideas than the same number of people who work alone and later pool their ideas.” Aha! Further proof that working alone is the answer, right? But it goes on to mention something more interesting and more subtle:
Pairs of subjects were shown a series of color slides in various shades of blue and asked to identify the colors. Sometimes one of the pair was actually a lab assistant instructed by Nemeth to provide a wrong answer. After a few minutes, the pairs were asked to free-associate about the colors they had seen. People who had been exposed to inaccurate descriptions came up with associations that were far more original.Working alone is good for creativity — but being paired with someone who thinks differently from you can lead to more creativity yet. So should your takeaway here be that pairing is the answer after all?
No, no, hell no. The true answer is that there is no one answer; that what works best is a dynamic combination of solitary, pair, and group work, depending on the context, using your best judgement. Paired programming definitely has its place. (Betteridge’s Law strikes again!) In some cases that place may even be “much of most days.” But insisting on 100 percent pairing is mindless dogma, and like all mindless dogma, ultimately counterproductive.
My own preference is a development environment where every feature/module/story has two programmers assigned to it, one “primary” and one “secondary.” (Terminology shamelessly stolen from Homicide/The Wire.) Each developer is primary on one feature and secondary on another. They pair-program from time to time, especially in the beginning, but in general the primary does most of the work, while the secondary spends an hour or two each day sanity-checking the primary’s code and building bite-sized subsections.
Alas, I’ve only worked like this a couple of times in all my decades of development. Those have been the most productive projects I’ve ever worked on…but that’s an extremely small sample size. Further research, as they always say, is needed. In the interim, I’ll leave you with one last quote from that Hacker News discussion:
“Yes, communal areas for some type of work/communication, private areas for others. It’s staggeringly obvious that this meets everyone’s needs … but I’ve found very few places offer anything remotely similar.”Image credit: Esti Alvarez, Flickr.
(1)Disclosure/disclaimer; I did a few months of contract work at Xtreme early last year.
Source:http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/
No comments:
Post a Comment