Team Code Ownership is “the ability for any developer on a team to change any of the team’s code.”
I’m presenting a paper on Team Code Ownership at EASE 2016 next week.
Summary of Paper
My observations clearly indicate that team code ownership is a feeling that can be engendered, not a policy that the team adopts
Pivotal developers more acutely feel team code ownership when i) they understand the system context; ii) they have contributed to the code in question; iii) they perceive code quality as high; iv) they believe the product will satisfy user needs; and v) they perceive team cohesion as high.
The paper shows that diverse events and trends that can undermine sense of ownership
The paper replaces Beck’s definition of Collective Code Ownership (“anyone can change any piece of code in the system at any time”) by introducing the new term Team Code Ownership (“the ability for any developer on a team to change any of the team’s code”)