Thursday, March 11, 2010

Pairing isn't the Solution

In 2007 & 2008 I wrote several blog entires on Pair Programming (tagged with pair programming). Pair programming solved a lot of problems for me: knowledge transfer, mentoring, code review, etc. It also solved another problem at the same time, even though I wasn't aware of it. Pairing helps reduce the number of cooks in the kitchen.

These days I'm working on a project with some really talented people. The pace at which we deliver features is far faster than any project I worked on before I joined DRW. However, I've seen two effects of having so many talented developers on the same team: wiki coding and spork sharing. (both metaphors coined by my tech lead, badams)

Wiki coding occurs when the churn on a class or component is so great that whoever commits last ends up deciding what it should do. Wiki coding leads to inconsistent design and lack of convention. Spork sharing occurs when a fork is designed and a spoon is also needed. Instead of creating a spoon, you want to share the handle, so you create a spork instead. Now, you have no spoon or fork, you have a spork, and sporks suck if you really want a spoon or a fork. Both problems seem to stem from differing vision for the classes or components.

It appears that the more talented programmers you put on a team, the more fractured the vision for the project becomes. Of course, complexity (as well as many other factors) can also increase the fracture.

You won't catch me advocating for 'hard-working average programmers'. What I do believe is: you should stock your team with only rockstars, between 2 and 4 of them. I've worked on teams that only had 3 people. I've worked on teams with about 16. I was a consultant, I've worked on a lot of teams - big and small. My experience was that the smaller teams were much more effective, every time.

Reflecting on the past few years, I came up with the following reasons for keeping your teams small:
  • New Technology: Small teams can more easily come to a decision to try a new technology. Also, if a small team selects a new technology, the entire team is likely to learn the new technology. However, an individual on a larger team may find a way to never learn the new technology and never contribute to that area of the code. Worse, a larger team may shy away from trying new technology because they cannot come to a consensus. New technology can offer productivity boosts, and missing those boosts can hurt a teams efficiency.
  • Smaller Problems: Smaller teams generally implies solving smaller problems. Most problems can be broken down into smaller, less complex problems. Once the problem is broken down, it should be easier for the small teams to craft elegant solutions that can integrate to solve the larger business need.
  • Improved Maintainability: Smaller teams generate less code, which allows all team members to have depth and breadth concerning a solution. Having depth and breadth allows you to easily share vision and fix broken windows.
  • Ownership: Ownership isn't bad. Single points of failure are bad, but having a small team that feels ownership over an application will generally lead to higher quality and more emotional attachment to it's success.
  • Context Switching: Smaller codebases maintained by small teams solving a smaller problem will context switch less, because there's nothing else to context switch to.
  • Responsibility: The Bystander Effect applies to code (e.g. production bugs) as well.
  • Unified Vision: In a large team it's easy to have an opposing vision and never be proven wrong. In a small team it's likely that you will agree on a vision for the project (process, technology, etc) as an entire team.
  • Adding: Adding one more person to a 2 person team will likely result in a new productive team member relatively quickly. Smaller team, smaller problem, smaller codebase = easier team to join.
Sometimes I wonder if consultancies sell large teams, and then use pairing to make the large teams more effective. It's definitely my experience that large teams pairing are much more effective than large teams that aren't pairing. However, I wonder if anyone ever stopped to ask: would a smaller team have been sufficient (or, better)?

I still believe pairing is an answer to many problems. However, the best solution to making a 8 person team more effective isn't pairing. I believe that a superior solution is finding a way to solve the problem with a smaller, more effective team (or teams).

11 comments:

  1. What exactly does a discussion of ideal team size have to do with whether pairing is good or evil? Nice attempt to titillate your audience, but I call BS on your headline. Why don't you instead talk about why it is that the developers on the team cannot agree on a design? Why is it that so few of the so-called "elite" developers in the world cannot learn when to follow, when to lead, and when to just get along? Those are the real questions you should address. Pairing has nothing to do with your actual topic.

    ReplyDelete
  2. Anonymous4:22 AM

    I would just like to say that I disagree with David. Smaller teams are suggested here as an alternative to pairing, which is the de-facto productivity improvement recourse in large teams. In my opinion the topic is relevant. I also do not believe you are trying to 'titillate' your audience. The advise is sound, and more importantly it comes from experience.

    This is just my opinion, and I voice it solely in the interest of balancing out the comments. I wouldn't want you to think we're all Davids.

    ReplyDelete
  3. We turn to pairing when our work-in-progress (WIP) limits kick in. I would not be at all surprised to find that limiting WIP (even if unintentionally) turns out to the real reason why large teams get more productive when they practice pairing.

    ReplyDelete
  4. You mention that pairing makes a large team more effective, but what effect does it have on a small team? Can pairing improve the effectiveness of a small team as well?

    ReplyDelete
  5. Anonymous9:38 AM

    Hello Tooky,
    I've found pairing to be successful at knowledge sharing and as an alternative to code reviews. I generally pair far more on on complicated problems or spaces of the code where I might be considered a single point of failure.
    Cheers, Jay

    ReplyDelete
  6. I think projects can benefit from pair programming at various stages. I dont feel its a yes or no issue, but rather getting the timing right.

    ReplyDelete
  7. Jay - I think this is insightful.

    Frankly, the only way you could be upset by the title and subsequent content is if you were hoping for a post that bashes Pair Programming and instead all you got was good advice.

    I too am a proponent of pairing. And I too struggle with appropriate team size. I find the ideal team size is significantly smaller than leadership is comfortable with. Nearly every time.

    Keep sharing your thoughts.

    ReplyDelete
  8. I gotta side with David. After reading this interesting article, my first reaction was that this post is not about pairing at all.

    You could title the post "why TDD is not the solution" and it would be the same BS.

    *We should all know by now that no single technique is a silver bullet.*

    But I enjoed the post and would like to see more articles on teams.

    Cheers!

    ReplyDelete
  9. I've also worked on teams big and small and noticed the same thing - small teams work much more efficiently. I've never been able to figure out whether this was due to the specific teams or simply due to human nature or something else completely.

    In terms of pair programming - it's a great practice and it really helps on teams of any size.

    ReplyDelete
  10. I agree that the best solution to making an 8 person team more effective isn't pairing (though it's a close second); at the same time, the 3-4 person group you replace the 8 with will be much better off if THEY pair.

    ReplyDelete
  11. Have you read The Wisdom of Teams? The general message is that there's a difference between a group of stars and a star team.

    ReplyDelete

Note: Only a member of this blog may post a comment.