BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Meeting the Challenge of Collective Code Ownership

| by Deborah Hartmann Preuss Follow 0 Followers on May 18, 2006. Estimated reading time: 2 minutes |
Martin Fowler has suggested that code ownership schemes fall into three broad groups, summarized here:
  • Strong code ownership breaks a code base into modules each, of which is assigned to one developer. Developers are only allowed to make changes to modules they own.
  • Weak code ownership is similar in that modules are assigned to owners, but different in that developers are allowed to change modules owned by other people.
  • Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. 
Collective code ownership is the model promoted in Extreme Programming, and many other Agile practitioners also have adopted it.  One reason is that it increases "truck factor", to the customer's advantage. In the past, the untimely loss of one developer could cripple a team's ability to deliver.  Ideally, with collective ownership, a rogue truck would (sadly) have to wipe out the whole team before development would stop. Individual expertise is respected in this model, but directed toward mentoring and knowledge-sharing rather than ownership.

This model requires high adherence to discipline on the part of the team, which may be new for some.  An undisciplined team will find collective ownership problematic, perhaps onerous.

Ken Schwaber, co-creator of the Scrum methodology, has long insisted that Agile processes must be adapted to their context - within reason, the approach must be ajusted over time to maximise value produced. The average team needs to search out the appropriate balance between pure practice and compromises for local issues and constraints.  Martin Fowler has brought us one such story: a team in trouble took a step back to improve their discipline, with the goal of once again returning to full collective ownership over time.  Using their more expert members as code reviewers, the team brushed up on the basic practices that support collective ownership.  In addition to the short-term gains of increased velocity and improved morale, their weaker developers improved their skills, which will benefit the whole team in the long run.

To quote Schwaber:
So, I'd say agility isn't a silver bullet, only a process that requires a lot of hard work, attention, caring, and teamwork.  But is agile a bitter pill?  Not if you consider it like fitness training - you try your hardest, day-by-day, and you get better and better at what you are doing.
Fowler's article recounts a colleague's story, in which one team had the courage to temporarily step back into "training", in order to move forward all the better.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT