Moving Toward Collective Code Ownership
Several months ago on InfoQ, Mark Levison posted Are there weaknesses with Collective Code Ownership? There is a comment on it that points to an excellent article on cm/crossroads: Situational Code Ownership: Dynamically Balancing Individual -vs- Collective Ownership by Steve Berczuk, Brad Appleton, and Robert Cowham.
Being relatively new to Smart Bear, I have been thinking about Collective Code Ownership (CCO) lately because I am trying to learn my way around some of the source code. I especially like the way the Berczuk/Appleton/Cowham article points out that CCO exists at one end of a spectrum. They recommend a balanced approach: Code Stewardship.
Read their entire article to get the full picture, but I was especially interested in this sentence:
Stewardship may ultimately end-up as collective-ownership if given a sufficient period of time with the same group of people.
But how does a team actually transition from stewardship to collective-ownership? The article specifically describes ways in which code-stewards for each part of a system are consulted, including pair-programming and code reviews; this practice serves a clear purpose:
The purpose of the protocol for consulting the code-steward is to ensure two-way communication and learning (and foster collaboration). That communication is a dialogue rather than a mere "token" transaction. It's not a one-way transfer of "control", but a two-way transfer of knowledge!
I sometimes see code review criticized as ineffectual because the reviewers of the code do not have enough context to provide meaningful feedback. Ironically, though, as the authors of the article point out, code review is one of the best ways in which to pull developers up the learning curve so that they can eventually provide meaningful feedback. In other words: Stop whining about how no one knows enough to
review your code and start explaining it to them during the