Collective Code Ownership

We are all responsible for high quality code. There is a metric for imposed risk by concentrating knowledge in just a few people's heads -- it's called the truck number. How many people can get hit by a truck before the project suffers irreparable harm? [Shore & Warden 2007]

Some developers consider this job security and, if you're in a company or state of mind where this is your sentiment, I sympathize with you. But it shouldn't be the case!

I often tell my clients that I only hire people that love what they do. My belief is that if you love what you do then your exuberance will be infectious and thus pollute the groundwater. You simply spend too many hours of your life "working" so why be unhappy while doing it? Honestly, if you can't stand your job, then you need to take action. That said...

As a team, we can't operate at 100% efficiency when we do not have redundancy. Things come up... Folks get sick, have emergencies, retire, go on vacations, you get the picture. Your project should not suffer when a team member can't make the game.

The concept of Collective Code Ownership (CCO) extends to all areas of development. When only one developer knows how to tweak the installer, it's time to refactor or educate.

CCO also applies to bug fixes... I know that I personally don't enjoy rooting around through broken code, especially when it's not my own! However, it's different when you weave it into your company culture. I subscribe to the old boyscout motto: Try and leave this world better than you found it.

Ideally, we don't have bugs because we're using TDD. But, let's be honest, we don't live in an ideal world and mistakes happen. I know that some of you would accuse me of rose color glasses syndrome but I assure you that this is not just Utopian dribble. It really works. That said, if you spend more than 15 minutes digging around and can't find the problem, it's probably time to rollback to the last working build.

[With CCO] No one person can be the bottleneck for change. [extremeprogramming.org]

Collective code ownership requires letting go of a little bit of ego. Rather than taking pride in your code, take pride in your team's code. [Shore & Warden 2007]

CCO is a tool. If it doesn't work for you, don't use it. My vote, always evolve. Don't scoff at a good idea because you'll never know if you don't at least try.

What does it mean to be done done?

If you ask the James Shore & Shane Warden, they'll tell you the following:

• Tested (all unit, integration, & customer tests finished)


• Coded (all code written)


• Designed (code refactored to the team's satisfaction)


• Integrated (the story works from end to end - typically, UI to database - and fits into the rest of the software)


• Builds (the build scripts include any new modules)


• Installs (the build script includes the story in the automated installer)


• Migrates (the build script updated database schema if necessary; the installer migrates data when appropriate)


• Reviewed (customers have reviewed the story and confirmed that it meets their expectations)


• Fixed (all known bugs have been fixed or scheduled as their own stories)


• Accepted (customers agree that the story is finished)

Can you run down this checklist at the close of an iteration and be certain that you've satisfied each bullet? If not, it's time to knock off a couple of the stories that you've committed to and focus on doing it right the first time.

Ward Cunningham on the Debt Metaphor

Ward Cunningham explains how he came up with the Debt Metaphor. I love how this stuff originates! He was working on finance software and needed to explain to his boss why it was important to refactor their existing code. He needed something that his boss could relate to.




Here's a good Cunningham quote from 1992 at OOPSLA:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." - Ward Cunningham