Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Opinion: Pair Programming Is Not For The Masses
Posted by Mike Bria on Sep 23, 2009
Pair Programming continues to be one of the most debated and controversial practices of recent years. Most proponents don't falter in their praise of the benefits, but many of even these same people will admit they struggle to get pairing really going in their shops. Why? Obie Fernandez opinions 10 reasons why this might be so.
After two of his company Hashrocket's employees, Desi McAdam and Jim Remsik, had an article on the benefits of pair programming featured in the New York Times, Obie followed up with a thought-provoking post outlining 10 reasons why many shops won't succeed with pair programming. He first qualifies his remarks explaining his pure belief in the benefits pairing exude, stating that he thinks "pair programming is one of [the] most important competitive advantages at Hashrocket".
He then follows by stating that "pair programming, especially all the time, is one of those things where [he] increasingly has to advise most Agile idealists that it probably won't work for them", and gives his list why:
- 10 - Most software managers don't want to invest in the necessary hardware: Effective pairing requires good equipment, and most shops aren't willing to make this investment
- 9 - Most software shops are not configured for pair programming: Most software shops have their programmers in cubicles, and "cubicles do not work for pair programming"
- 8 - Most software shops use traditional hiring practices: Good pairing implies having the right people for the environment, and many companies hiring practices don't contribute well to ensuring this
- 7 - Most software shops tolerate anti-social behavior: Pairing requires humility (or as Obie puts it, it requires enforcement of the "No-Asshole Rule"). Anti-social (and anti-hygienic) behavior and pairing don't mix, and many shops aren't diligent about removing bad mannered programmers
- 6 - Most software people don't understand pair productivity: The age-old misconception about pairing, "won't this cut my productivity in half?"
- 5 - Most software shops employ under-qualified developers
- 4 - Most software shops are overworked and under-staffed: Pairing, especially of the promiscuous sort, may require more people (but not necessarily more time), and many shops are not equipped for this
- 3 - Most software developers don't like everyone they work with: Unless you can commit to small teams of sociable people, you'll have a hard time getting people working together happily
- 2 - Most software developers just don't want to work that hard: Pair programming is intense and will lead you to working harder, but many people are not motivated to want to work this hard
- 1 - Most software shops don't really care about excellence: Investing in pairing implies investing in craftsmanship, which many shops aren't interested in doing
Obie's list (highly summarized here, please read in its entirety before making judgement), being rather opinionated, has generated a great deal of response, much of which available in the long list of comments on the blog entry itself.
Brian Guthrie took some time to create his own list in a noteworthy rebuttal to Obie's post. As he states:
[Obie's and] Hashrocket’s setup provides an optimum environment for pairing, but the folks who first came up with the practice didn’t have that kind of workspace available everywhere, and you don’t have to either.
He follows with this list of five things he believes Obie missed:
- 5 - Pair Programming Doesn’t Require Expensive Hardware: If it's all you can get, then one solid computer, some spare mice and keyboards, and a conference room will work to get started pairing
- 4 - Everybody Need Not Get Together And Love One Another Right Now: Don't pair people who don't work well together, and enforcing the basic hygiene pairing requires is something every shop should be able to do
- 3 - Many Businesses Are Happy To Try Pairing: Organizations aren't as afraid of pairing as people claim
- 2 - Many Software Shops Care Deeply About Return On Investment: Most shops aren't caring about "excellence" per se, but they do care about cutting down defects and spreading knowledge, which pairing does well
- 1 - Pair Programming Is Not Just For The Elite: Anyone can and likely will enjoy and benefit from pairing, not just "hard-core developers"
Take some time to read both posts, Obie's as well as Brian's, in full. Its likely many of the points will resonate one way or another with your own experience and ideas.
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Case Study: IBM's Agile Transformation
A practical guide to choosing the right agile tools
A Guide to Branching and Merging Patterns
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Both have good points
by
Ryan Riley
Posted
Elite ?
by
Baljeet Sandhu
Posted
Not again
by
Keis Keis
Posted
Re: Not again
by
Mike Bria
Posted
Re: Not again
by
Daniel Sobral
Posted
Again with the multiple keyboards
by
Curtis Cooley
Posted
Re: Again with the multiple keyboards
by
Mike Bria
Posted
It's a psychological issue in the first place
by
Abel Avram
Posted
Re: It's a psychological issue in the first place
by
Luis Espinal
Posted
10 wrong reasons -- you only need 1
by
Daniel Sobral
Posted
-
I think both Obie and Brian make solid points. In the environments I've worked in, however, Obie's points seem the most realistic. You may see opportunities for pairing in these environments, but they are not the norm and generally don't last due to manager/client intervention that it "looks bad" or normal employee turnover (whether due to project requirements or change of employment).
-
A have been an agile believer/practitioner for some time. This question was posed to me recently. 'Who exactly is an elite developer ?' Thinking about it, I can't see myself pointing to people in my company and tagging people as average or elite. This leads me to think that arguments for practices for 'elite developers' are not practical to implement. If a practice is proposed it must be applicable to all. Following that logic everyone would/should benefit from it.
-
Why most agile practitioners can just realise that pair programming doesn’t work. Instead they are creating some mythical “elite” developer, where by “elite” they of course understand themselves. Of course two people could potentially create better software as well as two drivers could drive a bus, two CEO run one company etc… But only in imaginary world. Communism also looks nice in theory, but does not work in practice. If you are so smart guys, you should see, that this does not work and stop acting like this is some sort of religion, where you have to “believe” in something.
-
Seriously? Keis (assuming this is your real name), it appears you are the one spouting dogma, asserting definitively "pair programming doesn’t work". Communism? Wow, quite an extreme analogy for someone who clearly has not given pair programming a fair shot first hand.
Cheers,
MB -
Not only does two keyboard != pair programming, but if you are new at it, having a keyboard and mouse in front of each developer will actually impede their understanding of how PP works. More at ponderingobjectorienteddesign.blogspot.com/2009...
To borrow Keis's analogy, two keyboards is like having two steering wheels in a car. The pair doesn't know who is supposed to be driving and who is supposed to be navigating. Take away one of the steering wheels and it becomes clear that each individual in the pair now have distinct and disparate responsibilities.
If you can't get two people to share a keyboard, how are they supposed to work together towards a common goal? Seems sharing is the first hurdle they need to overcome. You do them a disservice by removing it. -
Curtis,
I do hear what you're saying, that if people can't "share the keyboards", then they how can they share mind-space to work together towards the goal. Ie, sharing is key.
That said, in my experience the sharing is less a byproduct of a single keyboard, in the physical sense, then an understanding that you are sharing. That someone is driving and someone is navigating. Basically boils down to the obeying the usual verbal request for "the wheel" (ie, "mind if I drive?").
It just removes the somewhat awkward need to move a keyboard back and forth, which is doubly intrusive when there's a mouse that has to follow.
Trust me, I've done it both ways (for years), and have to agree with Obie that 2 boards/mice is smoother. Responsible Pairing required of course, but that's required no matter how boards you're weilding, eh?
Cheers,
MB -
Pair programming involves certain psychological mechanisms that not many people are comfortable with. Two people are physically close and need to be mentally close, thinking about the same problem, working together, more or less synchronized, joining their forces. Imagine two artists painting the same picture. It's quite rare. The higher the creativity needed to do the job, the harder is to find two people working together. Music, painting, sculpting, other arts, they are done mostly by individual persons. (Playing in an orchestra does not involve much creativity because the play has already been created. It involves a different talent.) Programming does not involve the same degree of creativity like painting, so pair programming is more feasible, but still difficult. This is an exercise that some people find very awkward. Some (probably a minority) have no problem, some can get used with it with some practice, and some will never do this successfully in their lifetime.
My suggestion: use pair programming only with people enjoying it. And remunerate them extra to make it attractive for others who can do it after some exercise. Let alone those who are not comfortable doing it. They will perform better if they are left alone. -
Pair programming involves certain psychological mechanisms that not many people are comfortable with. Two people are physically close and need to be mentally close, thinking about the same problem, working together, more or less synchronized, joining their forces. Imagine two artists painting the same picture. It's quite rare. The higher the creativity needed to do the job, the harder is to find two people working together. Music, painting, sculpting, other arts, they are done mostly by individual persons. (Playing in an orchestra does not involve much creativity because the play has already been created. It involves a different talent.) Programming does not involve the same degree of creativity like painting, so pair programming is more feasible, but still difficult. This is an exercise that some people find very awkward. Some (probably a minority) have no problem, some can get used with it with some practice, and some will never do this successfully in their lifetime.
My suggestion: use pair programming only with people enjoying it. And remunerate them extra to make it attractive for others who can do it after some exercise. Let alone those who are not comfortable doing it. They will perform better if they are left alone.
/end-thread.
Seriously. Abel hit it in the nail with this. There are fundamental psychological issues at hand that make pair programming not suitable in many cases, independently of the participating programmer's technical abilities (or lack thereof.)
I do take a lot of issue with Guthrie's counter points:* 5 - Pair Programming Doesn’t Require Expensive Hardware: If it's all you can get, then one solid computer, some spare mice and keyboards, and a conference room will work to get started pairing
A conference room is an expensive, usually scarce, asset. It's very rare than you can book one with the frequency and time-blocks required for development. I'm not sure what sort of foothold on reality could make one make such a suggestion.* 4 - Everybody Need Not Get Together And Love One Another Right Now: Don't pair people who don't work well together,
That's an oxymoron. What do you do when the majority of the programmers in the rooster do not work well together, that is in close proximity? How do break a deeply rooted psychological and cultural aversion?and enforcing the basic hygiene pairing requires is something every shop should be able to do
And a free-for-all capitalist economy should be able to regulate itself, and business should be able to hire only competent people without annoying personality traits. Unicorns should be cute, too.
Beyond the basics of hygiene, which are a sensitive topic to reach for in a business setting, there are also personality traits, accents, deeply rooted behaviors and thinking models that a business is better off leaving them be rather than trying to stamp them out just because "they should be able to."* 3 - Many Businesses Are Happy To Try Pairing: Organizations aren't as afraid of pairing as people claim
Care to quote numbers to back that up?* 2 - Many Software Shops Care Deeply About Return On Investment: Most shops aren't caring about "excellence" per se, but they do care about cutting down defects and spreading knowledge, which pairing does well
Weasel words. How many software shops are these? What is the proportion compared to the rest? What specific attributes make them so?
Saying that "many" exist not only amount to word weaseling, but, even if that were true (which I don't doubt they do), they do not provide evidence that what they work for them can be easily transplanted into another business/industrial context.* 1 - Pair Programming Is Not Just For The Elite: Anyone can and likely will enjoy and benefit from pairing, not just "hard-core developers"
Anyone can? Prove it. This is the type of unsubstantiated claim that really drives me up the wall sometimes. The suitability of pair programming is highly dependent on personality types, much more than on technical expertise.
I mean, seriously, "anyone can?". This is what I call projecting one's personality type onto others, expecting others will naturally have the same behavioral characteristics.
Pair programming can and will work, for those who have the psychological traits that make it work. That is not up to debate. It is a fact.
What is not a fact, what is debatable, and what constitute a gross logical fallacy is to assume that this implies or necessitates that it can be transplanted to others and reap the same benefits. It has no root in reality and completely ignores the fundamentals of human psychology. -
Obie's reasons are generally wrong. And they are particularly wrong when it comes to reasons 8 and 5. Pair programming, in fact, reduces individual deficiencies.
Now, some of the reasons are not reasons why pair programming "won't work", but reasons why people might not want to try it.
And some reasons are simple management problems, which any outfit wanting to try out pair programming can easily handle.
There's one reason why pair programming may not work, though: programming is culturally seen as an individual activity. Making cultural changes is hard. -
Go watch the Agile by the Numbers presentation here on InfoQ. To put it plainly, you are factually wrong.
10 comments
Watch Thread Reply