Pair programming LTD

November 22, 2008 at 8:20 am 1 comment

Pair programming is often recommended as one of agile techniques that help improve productivity, team chemistry and code quality. Unfortunately I have never seen it actually work the way it is described – two people sharing a desktop writing some code full time together. There is always something that prevents this happening.

For instance, developer A is very quick, write-it-first-than-think-about-it style. Developer B is more of the ok-lets-think-twice-before-we-press-a-button style. Both are good in their own way, each one can develop the feature in question in more or less same time and quality. Try to combine them together? Not so good. If B drives, A becomes bored and loses interest quickly. If A drives, B gets nervous and loses track of what’s going on.

If you say, well, just organize the team so that the people have same style, I am not going to agree with you. ๐Ÿ™‚

Diversity is good, as long as people are willing to work together (very important), different skill sets and styles are useful – some task are better suited for one or the other. And besides even if both developers were twins, there are still a bunch of factors that make pair programming difficult – outside interference, workstations not optimized for pairing etc.

So instead of “classic” pair programming we do a “limited” version of it. Well, the goal is to keep the collective ownership on the code (or at least on the tasks that do require it – not all bug fixes need to be looked at by two people for example). How it works? It’s very simple. Each “important” task is assigned two developers that are responsible for it – but we do not tell them that they have to work in pairs. Instead they are free to decide themselves how they want to split work. (BTW, this really emphasizes bottom-up style of agile). Some larger tasks may have even more people assigned to it.

So what follows is that the mini-team will some brainstorming together about the task AND the best way to accomplish it. After the main details are discusses and agreed they will usually split the actual mini-tasks and work solo and then integrate them together. For us this gives all the benefits of pair programming without the drawbacks and without the need to force people to “sit together”.

What do you think? Have you participated in long term pair programming teams? Or similar approach to ours is used? Anything else that can be done to improve it? Use the comments ๐Ÿ™‚

Advertisements

Entry filed under: Agile.

Struggling with sprint backlogs Agile hype cycle

1 Comment Add your own

  • 1. devdude  |  November 25, 2008 at 1:01 pm

    Yes, reality check will fail on pair programming. the only time it works is debugging or code review (on the level). Most developers I met or I worked with don’t even have similar work patterns (timing, environment setup like screen or “chair” and keyboard arrangement,..).
    Sven (http://javadude.wordpress.com)

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Calendar

November 2008
S M T W T F S
    Dec »
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Most Recent Posts


%d bloggers like this: