Welcome to

Magenic Technologies Community Blog

Sign in | Join | Help

Aaron's Technology Musings

Who let this guy on the podium?

Pair Programming - Marketing FAIL

When people talk about lack of adoption of "XP" (aka Extreme Programming) practices, one of the chief problems people have with it is the idea of "Pair Programming".  There are more times than I can count where I have been in conversations, where something along the lines of "those crazy agile guys want to have 2 developers do the work of 1 - no way we are doing agile" becomes part of the conversation.  What an amazing failure of marketing.  It is proof that before anyone in the software development business wants to come up with a great idea, they should run it by some people in marketing to see if the thing will fly.

Lets talk about some of the benefits of Pair Programming.  When you are working with someone else, you are not:

* Surfing the web reading SlashDot/DIGG/etc.together

* Reading personal email

* Writing personal email

* Shopping on amazon.com

* Playing solitare

* Letting your ego continue to pound away at a problem that, for whatever reason, you can't solve.  Your person you are pairing with should not have the patience for you to take them on "wild goose chases"

* Getting interrupted by others - people are much more reluctant to interrupt two people who are activley solving a problem than one person quietly contemplating 

Rather...

* You are pacing eachother - people tend to run faster in races when they can directly work with eachother and co-motivate

* You are collaborating - two bright people should have a broader knowledge base than one single person 

* You are active - walking into a team where people are activley collaborating looks like more "active" work than one where people are silently poring over their screens

* You are sharing knowledge - pairs can cross-pollenate good ideas that working alone we have to work harder to see.  We seldom watch others program - and pick up from eachother little productivity habits (keystroke shortcuts, etc.)

The focus you get from pairing, so long as you are not paired with a psychopath, are immense.  Pairing should generate the work of 3 people based on the productivity gains.  It makes surface sense - when pairing, you are much more likely to get the 8 full professional hours per person than you are otherwise.

So why does this not sell?  Seems like the benefits are pretty darn obvious.  Well, personally, I believe the branding and naming of XP is one of the biggest marketing failures in history.  CIOs are a conservative bunch.  So are business owners.  Like it or not, most of the time, they have to approve budgets, projects, and investments.  Unless I have read a TON of literature and are ready to take on faith that it will work, if I am a CIO and my job depends on it, I ain't doing "Extreme" lunch, much less "Extreme Programming".  I like having a BMW in the garage and not living on Ramen, ThankYouVeryMuch.

My modest proposal is to stop calling it Pair Programming or Extreme Programming.  At this point, that is like calling your new energy company Enron.  I propose calling it Collaborative Development.  If we have two people on a project, they collaborate to get things done faster.  And we leave it at that.  Then, when we get things done faster and can point to good results, then we can talk about how good our new "methods" are. 

Published Wednesday, November 19, 2008 12:47 PM by aarone

Comments

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 12:12 PM

well said - I've encountered this myself many times

garybr

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 1:09 PM

I find that pairing is good for debugging, trying to figure out why something is not working. When I am coding, though, I want solitude. When someone is sitting next to me, I cannot concentrate on what I am doing. A large part of my brain seems to be occupied by "Hm, I wonder what he thinks?" so I cannot really do any work.

keshet

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 1:46 PM

One you may have left off, for places where code reviews are done: continuously reviewing code.

Good points, all of them.

Sammy Larbi

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 3:11 PM

Well one other thing you will not do during pair programming is reading this blog...

Overall marketing XP under a different name seems like a good solution especially when dealing with management. This, however is just the first obstacle, you will still have to go over your list of arguments once they hear of "two people on the same computer". Very few people concerned with expenses can see beyond their argument of "paying double for the code".

And then assuming XP has won the argument, it still needs to prove itself - sometimes it does sometimes it does not, it depends a lot on the culture and the people practicing it.

mike

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 3:34 PM

I find that pairing is distracting while coding,

okay for debugging, and great for integrating.  I'd rather have a badger in my pants than another warm body around while coding, but it's really useful when trying to get a lot of code (written by different people) to work and play well together.

Brian

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 3:36 PM

How about synergistic development?

newname

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 3:37 PM

I agree with keshet - except for me, having a person sat next to me seems to leave almost all my brain occupied with "aargh! a person is sitting next to me! am I breathing annoyingly? what is he thinking? am I boring him? can he smell me? I know I showered, but..." and a similar tailspin of utterly productivity-destroying thoughts. There is nothing that works for everybody, and pair programming, for me, would be a resigning issue - simply because I'd rather resign now than go on the sick, ragged from unbearable stress, in three weeks, never to return.

gwenhwyfaer

# Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 4:05 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

DotNetKicks.com

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 4:28 PM

The other one is SCRUM - which, as a word/concept to marketing is just horrible. First off, it just sounds dirty. Second off, it refers to a rugby term, which if any programmers have heard off, is something they definitely don't want to get involved in - its a messy, violent, muscular shoving match between two teams of players - not really what you want from your development team.

damien

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 5:39 PM

I think your faith in pair programming is a bit naïve.  According to a scientific study in Norway, pair programming seems to work well for junior programmers, but it appears to be a lot less beneficial for more senior programmers.

Of course, there are activities where working in pairs has its advantages.  I often debug with other people, or I discuss design while we look at code together.  I sometimes also work in tandem with others when I need to explain a piece of code.

I am rarely productive when pair programming.  It slows me down.  I use multiple screens and I have a very non-linear way of writing code.  I usually have 2-3 activities going at the same time.  It is confusing to watch -- even more so when I am "in the zone" and things progress rapidly.

If someone interrupts me while I have Flow it can ruin hours of productivity.

I suck at staring at other people I work too.  I get frustrated by looking at them do some things in painfully awkward ways as well as having to ask them "how did you do that" when they have some super-efficient way of doing something quicker than I can see.  Even worse is when I don't understand where they are going -- which often happens when I try to pair program with someone whose non-linear workflow resembles mine.

For me, pair programming kills focus, kills concentration and kills productivity.  And it was enlightening to learn that others had discovered the same thing through scientific studies:  that pair programming works for a very limited set of circumstances.

Save the above piece (your blog posting) and read it again in 10 years.  Believe me.  10 years is going to whizz by fast and if you look at that piece again in 10 years, you are going to be embarrassed at your youthful cocksureness.

I know.  Because I have a habit of keeping notebooks and revisiting my notes 1-2-5-10 years later.  It is highly educational, it keeps you sharp and it is also very humbling.

As for pair programming, if you are a software engineering fashionista, you are half a decade late.  The reports are in and the verdict is that this bullet was not made of silver either.

(The upside is, when the next fashionable thing in software engineering sweeps the conference circuit, you will have acquired a healthy dose of skepticism).

Sim

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 6:09 PM

Sim-

Believe me - I am as big of a skeptic as they come with this stuff.  That is probably why I am 5 years late.

Believe me, it isn't a silver bullet.  But can it help focus when the collaborators are right?  Sure.

I do wish there were studies about this that were not written by people with an agenda for or against the practice.  Sure, I can see why someone would not want to do it.  Hell, in my own personal work on open source, I don't practice what I preach in this very post.  But frankly, I don't think we know - one way or the other.  And in my thoughts about it, I can clearly see what the benefits would be, especially with a good pair that can learn from eachother and work well together.

aarone

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 6:32 PM

Some programmers I know at a large company did exactly that back in 2005: they called it "Collaborative Programming". They were very successful.

Alan

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 6:37 PM

So you don't practice it, but you advocate it...

Matt

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 6:50 PM

"Letting your ego continue to pound away at a problem that, for whatever reason, you can't solve." LOL! I spent eight hours working on a Data Controller with an NSMutableDictionary that wouldnt work... even though I knew there were other ways to send the variables!

Nerdhappy

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 6:53 PM

Matt-

In my corporate work, I practice it.  In my open source work, I don't.  But the latter is something I self-starting anyway, not doing under someone else's money.  If I am less productive, my time is the only thing I lose.  Wholly different deal.

aarone

# re: Pair Programming - Marketing FAIL @ Wednesday, November 19, 2008 8:02 PM

This has proven to not work in several of the places I have worked, the problem is that you usually end up slowing down a senior person.  Two seniors together is a waste of time and effort.  They would tend to ask someone when they run into a problem hence there is no real benefit of working directly with another.

Mike

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 1:13 AM

I think the points you have identified in the post are right, but there are also a number of factors you haven't identified, some have been mentioned in the comments. As a senior programmer I feel that this is a "blunt instrument". If I need an extra pair of eyes or ears for a problem, I would ask for it. Typically senior programmers seek each others advice on finding optimal design solutions. After that has been discussed, there is limited value in watching the actual line by line implementation being written down. Sure things do pop up while programming all the time, but they can be either solved independently or in case they are show stoppers, be brought into reconsideration with your peers unless you can readily figure out the optimal solution. Saying you should pair program "just because" is an inflexible approach, sort of like saying "hammer works for nearly any purpose". Part of seniority is the repertoire of learned approaches and tools for different problems, and the ability to discuss each design's pros and cons with your peers. Now, you're probably right about being forced to focus, but I'm not sure I actually want a person sitting behind me just for that purpose. In fact you could probably hire a cheaper person than a programmer for that role.

Mark

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 1:19 AM

well, i can clearly see its benefits, but you definitely need 2 bright and active people for it ready to give their best to solve the problem.

The thinking of both must be aligned and narrowed to a single tube; which i think sometime is difficult...however i definitely want to practice it ;)

Anjan Saha

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 2:32 AM

As a professional software developer, I must state that the idea of pair programming scares the crap out of me.

I LIKE visiting Digg/Slashdot/Reddit.

I LIKE reading and writing personal mail.

I LIKE pretending to work and playing flash games.

I LIKE shopping on eBay while at work.

And all the rest of that stuff...

I don't think it hurts my productivity, either. I code crazy fast and relatively error-free, I write algorithms that are stable and efficient, and when I get locked into a problem there's no prying me away. But leave me my digg/ebay/tower defense time!

Amnon

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 8:36 AM

If I had to be locked in a cube with someone else for 8+ hours a day I'd have a hard time getting up and going to work in the morning.  

What a miserable way to spend the day.

Somebody

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 9:11 AM

When I was forced to Pair Program in University I thought the Professor was joking / out of computer terminals.

I'm now the only Paired Programming Proponent at work :P

It rocks and I force my newbie programmers to code with me.  It's great because we get to build a good working relationship, they pick up a lot of techniques quickly, and yeah...no facebook.

Aaron

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 9:39 AM

Although the reasons you mention may be valid, I don't think they'll sell from a management perspective. All of those things you've mentioned would probably be met by the remark "well you shouldn't be doing those things anyway - what do we pay you for?" More enlightened managers may not say this, but then you with them you probably have more free reign over how you choose to allocate people to problems anyway, meaning that they're not the sort that would object to experimenting with pair programming.

Andrew Cherry

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 9:47 AM

Andrew-

You are right.  The proof would be in the pudding - everyone and their mother has heard promises from the software development industry.

The best reason to do it is for the sake of your own productivity, and that of your team.  When you get enough results doing it, the market will speak and others will demand the technique.

That said, the thing I really wanted to point out (hence, Marketing FAIL) - is that you could have the best product in the world, but if you call it PooFlingersForBreakfast, it will probably not get many buyers.

aarone

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 11:05 AM

I'm all for joint up front design, code reviews and getting help with debugging.  But actually _coding_ with someone all day long would be a deal breaker for me.  If you're a senior programmer, watching someone type for an hour isn't really going to provide much benefit.  If anything, it would be really quite annoying.  

Also, if I'm in the coding 'zone' the last thing I want to do is hand over the keyboard to someone else, or spend time worrying about what they're thinking.

If I find myself stuck on something, then I go ask my co-workers and vice versa.  Has always worked out really rather well in every shop I've worked in.

Robert Morris

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 11:11 AM

What do you think about creating a triplet, by having a project manager supervise the session. My guess is upper management would have a better sense that there will be productivity if you did that. Also, that PM could be in a chair that rotates so that depending on whether they are facing south, north-east, south-west, etc, they get to 'tune in' to another set of collaborators. This will require rearranging the office layout into star patterns, and erecting walls and glass structures if necessary, along with an audio mixer and headset/mic within arms reach of the PM.

Jon

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 12:33 PM

Pair programming doesn't consider basic human psychology. If programmers were robots, it might work ok. But in reality, programmers are (usually) anti-social, egotistical, introvertive humans. The reason many programmers even get into computers to begin with is a natural tendency to shy away from social interaction. This is a gross generalization, but statistically relevant.

cc

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 12:47 PM

Why should two senior programmer pair? You always have somebody junior on the team, with whom they can pair and mentor them. Apart from focus and productivity, mentoring is also a very important part of pairing. The junior programmer will learn a lot from them and will be productive faster than otherwise reading some documents.

Shishir

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 1:12 PM

Great post but I think you may have missed the biggest benefit of pair programming: refactoring. When people start XP it is almost always on a green-field development, In my experience, the efficiencies of pair programming really kick in when you're getting into the nth iteration of development. Two programmers working together get to the root of understanding an application much quicker, and also are more likely to spot the unintended consequence of the  proverbial "one line change". Look at the man-hours an application consumes over it's life and it is the maintenance and enhancement that consumes the vast proportion.

Dave Mac

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 3:03 PM

Regarding "so long as you are not paired with a psychopath": technically, psychopathy is about a deficit of conscience. I would think it should be possible to pair with someone who scores high on a PCL-R test. It just might be a little unsettling sometimes. You might feel manipulated. However, I am not speaking from experience on this.

As for actual reasons a person might not pair, I am sure there are many, and I am sure they are mostly more innocuous than psychopathy. Here are my educated guesses: strongly ingrained habits, personality, interpersonal skills and relationships, ego, resistance to change, fear of meritocracy, unwillingness to learn, and plain ol' doubts and misconceptions.... I'm sure this list is incomplete, but I'll bet even avid pair programmers will find something in there to identify with. There is really a serious green eggs and ham problem with pair programming, even though it's just about side-by-side collaboration, which people will do willingly in other contexts. Some cooks won't share their kitchen. It's a personal issue.

If your developers have never given pair programming a sincere try, they are usually willing to try it for 2-4 weeks in earnest, which should be enough to clear up most misconceptions and get what it's like to collaborate on programming problems. But after that, they definitely need a viable exit strategy. It's not just the humane thing to do, but a long-suffering resister will never quite get it right, and encourage bad pairing habits in the other members.

Anyway, I'm rambling. The main point of the post, about bad naming, is excellent. My pet peeves are "sprint" (for falsely implying that software projects are like a series of sprints, not a marathon), and "velocity" (for falsely implying a measure of productivity, whereas no such metric exists; it's just a planning tool).

Alan

# re: Pair Programming - Marketing FAIL @ Thursday, November 20, 2008 4:31 PM

If you consider a pairing session to consist of staring at someone else typing in code then you have mentally checked out of the process because you are incapable of adding value to it. Unilaterally these developers are not nearly as good as they seem to think they are and never improve as they choose to pass on learning opportunities.

jl

# re: Pair Programming - Marketing FAIL @ Friday, November 21, 2008 12:30 AM

Wow, nothing like stirring up a little passion! Great to see such an energetic debate.

Definitely, the choice of language and the 'marketing' of development techniques is important and it is essential to focus on the benefits and outcomes of any particular practise rather than the technicalities. Management want to know about the quality improvements, the speed to deliver, the shortening of getting a new developer productive etc.

Pair Programming definitely has its place and require one major presonality trait to work well. That is a lack of Ego. A lot of the detractors arguments mask ego related issues.

That said, to apply the technique 24x7 for the whole team is niave and takes the focus away from achieving the desired outcomes and keeps it on complying with a methodology.

Pair Program for as much time as it makes sense in order to ...

- Skill up a new team member

- Make good design and architecture decisions

- Re-factor

- problem solve/bug fix

- ensure focus and productivity are high.

This will be different for different teams and projects, and could be anything from a couple of hours a day to full time.

Derek Winter

# re: Pair Programming - Marketing FAIL @ Saturday, November 22, 2008 6:24 AM

crappy pair programming.

From my personal experience in the company I am working for, I have nearly lost relationship with whoever I paired with. In the next day, I couldn't just go over to the person and say hi to him.

There are always contexts in which you may want to use pair programming. Like mentoring a new guy joined in the team. I have wasted so many hours sitting with the other person in the work.

I don't disagree with benefits by pair programming. It provides lots of benefits. I learnt a lot too from other programmers, but I never like to sit with a person who is considered a colleague not a friend.

Once get pair with the person you don't like in the team. You will obviously get to know the pain...

I was on the verge of resigning the job just because of the effect of pair programming.

Gujili

# Wrong Point Of View @ Saturday, November 22, 2008 6:37 AM

Aaron, you are looking at this completely wrong. The best results are achieved by capable, motivated team period. Forcing teams to use pair programming (or almost any other agile practice) against their will is the reason why agile can fail. Pair programming (or whatever the name is) is a tool, some people will like it, some people wont. Let your developers decide what works best for them

Gregory Mostizky

# Selling XP @ Saturday, November 22, 2008 6:41 AM

One more thing. When "selling" XP or agile you are selling to both team members and management. Management doesnt care about things you write about - they care about deadlines, quality, visibility and so on. As for team members, I dont think they will particularly care for "not being able to surf amazon.com" either. To sell them pair programming you should talk about expanding knowledge, eliminating bugs and need to stay late, things like that.

Gregory Mostizky

# re: Pair Programming - Marketing FAIL @ Saturday, November 22, 2008 7:51 AM

Gregory-

I definitely agree with your second comment, as well as elements of your first.  And frankly, I would never force developers to do anything they don't buy in to - at least on a regular basis (though I will ask them to try and be open minded about it).

This sentence, from my post, is pretty important: "Then, when we get things done faster and can point to good results, then we can talk about how good our new "methods" are. "

I would rather go to my clients with results, rather than ideas.  That way, after credibility is established, I can be a lot more persuasive about process matters.  More often than not, clients are coming to me saying we want more quality, and shorter iterations.  Sometimes, they don't want to call it agile, because of some of the bad marketing and the religious fervor around it, but they *do* want to commit to less time up front, higher quality code, and a more committed team.  So when appropriate, we use tools like pair programming (eh, I mean "collaborative development" :) ) - to get there.

It is a bit different in consulting.  Consulting, isn't just contracting (though it is often confused).  It is a little more soft skill driven than simply programming is.  In my experience (and this probably isn't universal) - it means consultants are a little more used to collaborative development techniques.  We see being able to effectively perform effectively in a pair being a gateway to more high profile gigs helping to open up new clients via mentoring.

aarone

# Trolls and Douchebags @ Saturday, November 22, 2008 12:53 PM

Aaron, you are *way* to civil in all this. http://geekswithblogs.net/dlussier/archive/2008/11/22/127311.aspx http://geekswithblogs.net/dlussier/archive/2008/11/22/127311.aspx D

D'Arcy from Winnipeg

# re: Pair Programming - Marketing FAIL @ Saturday, November 22, 2008 1:39 PM

Sorry...here's my Part 1 post. :) http://geekswithblogs.net/dlussier/archive/2008/11/22/127312.aspx

D'Arcy from Winnipeg

# re: Pair Programming - Marketing FAIL @ Saturday, November 22, 2008 2:50 PM

I'd be happy if my project manager were forced to sit with me. The number of times damn managers come up with "Well I don't know, you have to tell me how long X will take, I am not a programmer". I end up with far less technical issues I cannot overcome as those that relate to management understanding how to schedule correctly.

nexo

# re: Pair Programming - Marketing FAIL @ Saturday, November 22, 2008 2:51 PM

I'd be happy if my project manager were forced to sit with me. The number of times damn managers come up with "Well I don't know, you have to tell me how long X will take, I am not a programmer". I end up with far less technical issues I cannot overcome as those that relate to management understanding how to schedule correctly.

nexo

# re: Pair Programming - Marketing FAIL @ Wednesday, November 26, 2008 3:53 PM

You're right about what's not happening when you're pair programming.

"Extreme Programming" isn't a good moniker. I'm not a bungee jumper or skateboarder. I build software.

Your "modest" proposal isn't that modest. A lot of momentum is behind the term "Pair Programming." It provides a visual of two programmers at the same computer. "Collaborative Development" sounds like you're talking about Microsoft Sharepoint three years ago.

The term "Pair Programming" is the one that will stick. However, it does need constant selling on the points you describe.

Good post.

Dan Croak

# re: Pair Programming - Marketing FAIL @ Wednesday, November 26, 2008 5:13 PM

My understanding is that the term XP was deliberately coined to avoid being attractive to management. Look at all the crap that people now get away with describing as 'agile' to see what happens when a good idea falls prey to the buzzword management crowd.

Kerry Buckley

# re: Pair Programming - Marketing FAIL @ Friday, November 28, 2008 2:15 AM

They're not looking at it from an accounting perspective. It's not twice as many programmers, it's half as many computers. :)

J.T. Hurley

# re: Pair Programming - Marketing FAIL @ Friday, November 28, 2008 9:28 AM

@Kerry-

Heh - if that was the goal, they succeeded wildly.

Exactly, why would you want management (i.e. the people who get projects funded for the vast majority of programmers) - interested in agile or XP.

aarone

# re: Pair Programming - Marketing FAIL @ Saturday, November 29, 2008 3:09 PM

Pure genius!

While I am a self admitted newb to C#, developing in general, I do come from an extensive IT background (server/network).  I can tell you as a matter of fact 2 good collaborators work better than 3 individuals.  I myself want desperately to find a coding partner because I know the associated drive that comes from a pair environment.  

I LIKE my surfing to, but I find I getting more surfing done having completed my projects in a pair/collaborative situation then if I had to do it alone.

Don't get me wrong, developing can be done in a solo environment, especially if your a guru, I just think people feel more confident and fulfilled when a project is developed in a pair environment.

Jimmy Ford

New Comments to this post are disabled
Powered by Community Server, by Telligent Systems