|
In my recent CodeOwnership post, I described the way in which I
think about code ownership issues. Many of my software development
friends are extreme programmers, and tend to favor collective code
ownership. However these kind of practices aren't absolute and
should always be tempered by local considerations. One of my
colleagues sent me a note with the following story which I thought
was a good indication of when you have to vary your practices, even
if you are a strong fan of XP. (As he's talking about his team, he
prefers to be anonymous.)
I shifted our team from the "collective" to "weak"
model, in order to counter some undisciplined programming by a couple
of developers. Combined with some rather candid feedback, the result
was a gain in velocity since the programmers who now "own" our key
code areas are not constantly reworking sub-par code, while those that
were doing sub-par work in those critcal areas are instead doing
things like bug hunting and low-risk code changes -- which further
frees up the others.
We also had a net gain in morale, since everyone but the sub-par
producers were getting frustrated by having to watch their every
check-in for issues, and fixing the problems that they didn't catch in
time. This change rewarded those who took quality, TDD,
non-speculation, etc. seriously.
However, we also needed some additional practices and policies to
counterbalance:
- More frequent pair switching (our actual policy is that you can
still work on any part of the code, but if its in an area other than
one where you have "free play", you need to pair with someone who
does, or heavily vet your ideas through them first)
- The way back in is through the owners. If they feel comfortable that
your code will be up to snuff, you can take tasks freely there again.
- If things don't improve, then we'll have to take further steps.
It's been very educational for me, because I never had to go this far
before, and I was really reluctant to "play the heavy." It was really
tough for me to introduce a directing instead of an enabling practice,
but things have been much improved since.
This kind of local adaptation is an essential part of extreme
programming, or any agile method. All things being equal my
colleague still prefers collective code ownership, but all things
are seldom equal.
|