Taking a Second Look at Collective Code Ownership
Join the DZone community and get the full member experience.
Join For FreeIt'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.
From http://blog.jayfields.com/2010/11/taking-second-look-at-collective-code.html
Opinions expressed by DZone contributors are their own.
Comments