Tuesday, November 30, 2010

Taking a Second Look at Collective Code Ownership

It's common to hear proponents of Agile discussing the benefits of collective code ownership. The benefits can be undeniable. Sharing knowledge ensures at least one other perspective and drastically reduces Bus Risk. However, sharing comes at a cost: time. The ROI of sharing with a few people can be greatly different than the ROI of sharing with 5 or more people.

I do believe in the benefits of collective code ownership. Collective code ownership is a step towards taking an underachieving team and turning them into a good team. However, I'm becoming more and more convinced that it's not the way to take good team and make them great.

(context: I believe these ideas apply to teams larger than 3. Teams of 2-3 should likely be working with everyone on everything.)

If you pair program, you will incur a context switch every time you rotate pairs. Context switches always have a non-zero cost, and the more you work on, the larger the context switch is likely to be. Teams where everyone works on everything are very likely paying for expensive context switches on a regular basis. In fact, the words Context Switch are often used specifically to point out the cost.

Working on everything also ensures a non-trivial amount of time ramping up on whatever code you are about to start working on. Sometimes you work on something you know fairly well. Other times you're working on something you've never seen before. Working on something you've never seen before creates two choices (assuming pair-programming): go along for the ride, understanding little - or - slow your pair down significantly while they explain what's going on.

Let's say you choose to slow your pair down for the full explanation: was it worth it? If you're the only other person that knows the component, it's very likely that it was worth it. What if everyone else on the team already knows that component deeply? Well, if they all die, you can maintain the app, but I don't think that's going to be the largest issue on the team.

(the same ideas apply if you don't pair-program, except you don't have the "go along for the ride" option)

I can hear some of you right now: We rotate enough that the context switch is virtually free and because we rotate so much there's little ramp up time. You might be right. Your problem domain might be so simple that jumping on and off of parts of your system is virtually free. However, if you're domain is complex in anyway, I think you're underestimating the cost of context switches and ramp up time. Also, the devil is traditionally in the details, so you're "simple domain" probably isn't as simple as you think.

Let's assume your domain is that simple: it might be cheaper to rewrite the software than take your Bus Number from 3 to 4.

Another benefit of pair programming combined with collective code ownership is bringing up everyone's skill level to that of the most skilled team member. In my opinion, that's something you need to worry about on an underachieving team, not a good team. If you're on a good team, it's likely that you can learn just as much from any member of your team; therefore, you are not losing anything by sticking to working with just a few of them in specific areas. You really only run into an education problem if you're team has more learners than mentors - and, in that case, you're not ready to worry about going from good to great.

There's also opportunity cost of not sticking to certain areas. Focusing on a problem allows you to create better solutions. Specifically, it allows you to create a vision of what needs to be done, work towards that vision and constantly revise where necessary.

Mark Twain once wrote that his letters would be shorter if he had more time. The same is often true of software. The simplest solution is not always the most obvious. If you're jumping from problem to problem, you're more likely to create an inferior solution. You'll solve problems, but you'll be creating higher maintenance costs for the project in the long term.

Instead, I often find it very helpful to ponder a problem and create a more simple and, very often, a more concise solution. In my experience, the maintenance costs are also greatly reduced by the simplified, condensed solution.

I'd like to repeat for clarity: Collective code ownership has benefits. There's no doubt that it is better to have everyone work on everything than have everyone focused on individual parts of the codebase. However, it's worth considering the cost of complete sharing if you are trying to move from good to great.

6 comments:

  1. Isn't another benefit analogous to how TDD/BDD improves design? (Testable code is better code, code that satisfies a well-expressed behavior is more likely to have a single responsibility, etc.)

    As you mention, the cost of context-switching is the biggest imposed by collective code ownership. But this should drive us to try to lower the cost, by minimizing the difficulty of context-switching. This can be the driving force behind designing for readability/maintainability, automated builds, convention-over-configuration, automating dev-setup, etc.

    I just wanted to add this to the benefits side of the equation. I'd tend to agree, that just as on a great team you might not feel the need to use TDD on every level of code to drive design (because you've all internalized good design, or whatever), a great team may not need collective code ownership to reinforce a focus on these positive aspects of software design. But for a lesser team this can be a key factor in understanding WHY we do all of these "best practices."

    I'll also say I've never tried true collective ownership with groups larger than 3, so that cut off point also feels right.

    ReplyDelete
  2. This story suggests that there might be benefits to context-switching. Promiscuous Pairing and the Beginner's Mind (PDF)

    ReplyDelete
  3. Bill, there may be benefits. The question is: at what cost?

    Context is everything.

    If I work for a trading firm (that employs outstanding programmers) and I want good diversity and have zero appetite for bugs, I want 2 or 3 people focused on certain areas of the codebase.

    However, if I own a consultancy that is always trying to train-up new-hires, I want maximum exposure for all employees so I can teach my people on the clients dime.

    Each context is different. I'm not suggesting one way is better than another. Rather, you should look at your context and determine if the recipe you are following could be tweaked to better fit your context.

    ReplyDelete
  4. Jay,

    My apologies. When I commented earlier I was short on time and was not able to give more context. :-)

    It was not my intent to contradict you. Context is very important.

    Determining the best method for a given context may be somewhat counter-intuitive, though. The article that I linked to earlier says that in a pairing situation the context-switch itself can actually produce more innovative solutions and better designs.

    Given that, the method that is used to evaluate a given context is very important.

    ReplyDelete
  5. Agreed Bill. Thanks for the comment.

    ReplyDelete
  6. You might want to take another look at the promiscuous pairing paper. That team measured that they went faster when they switched frequently--and this was a complex application in C++. Their point was that it's worth experimenting to see what happens.

    We tried the experiment on my team when the paper came out and it didn't work for us, but at least we then had some data.

    ReplyDelete

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