Balancing Individual versus Collective Code Ownership


This can be accomplished by pairing with the code-steward, or simply by seeking them out as an FDD programmer would a Chief programmer/architect. The code-steward is like the "editor-in-chief" of the module or class. They do not make all the changes, but their knowledge and expertise is still applied throughout. The benefits are:

  • Concurrent changes can still be made and wait-times avoided while still permitting notifications and coordination
  • Knowledge is still disseminated (rather than hoarded) and spread-around the team
  • Collective ownership and its practices, such as refactoring, are still enabled
  • Pair programming can still be done, where pairing assignments can be based in part on who the "steward" is for a piece of code. (At some point stewards can even hand-off-the baton to another)

The bottom-line is that collaborative ownership and authorship is still essential. Code ownership isn't supposed to be solely about controlling concurrent access (and is very suboptimal as a concurrency-strategy, even though some merge-a-phobic shops will swear by it). Code ownership is also about safeguarding the integrity and consistency of the design and implementation, and also about disseminating knowledge of the owned module/class, as well as knowledge of practices and patterns for its succful "care and feeding." If we take "ownership" to either extreme, and keep it there—the result is impractical and imbalanced.

When Brad presented the notion of Code-Stewardshop on several agile forums, he received a great deal of feedback. Most apparent was that he had utterly failed to successfully convey what it was. Despite repeated statements that stewardship was not about code access, it seems everyone who read it thought the code steward, as described, was basically a "gatekeeper" from whom others must acquire some "write-token" for permission to edit a class/module.

That is not how it works. The code-steward serves as a mentor and trail-guide to the knowledge in the code. Consulting the code-steward is not about getting permission, it is about receiving knowledge and guidance:

  • 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!

Perhaps a better way of describing it would be the way Peter Block defines stewardship in his book of the same name Stewardship: Choosing Service over Self-Interest

  • Stewardship is being accountable to the larger team or organization by "operating in service, rather than in control, of those around us"
  • "We choose service over self-interest most powerfully when we build the capacity of the next generation to govern themselves"
  • Stewardship offers a model of partnership that distributes the power of choice and resources to each individual
  • Stewardship is personal—everyone is responsible for outcomes; mutual trust is the basic building block, and the willingness to risk and be vulnerable is a given
  • Total honesty is critical. End secrecy. Give knowledge away because it is a form of power

About the author

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.