The benefits of collective code ownership are well-known. Everyone in the team needs to be able to contribute to every part of the code base. But collective code ownership has an Achilles heel. The quality of the code can degrade as team members try to evolve unfamiliar parts of the code base under schedule pressure. As innovators and craftsmen, programmers take pride in their work. And they need the satisfaction of seeing their carefully crafted designs evolved by the rest of the team without losing their conceptual integrity.

There is, of course, an ideal of a gelled team in which communication is so rich that all team members will do the right thing instinctively as they evolve different parts of the code. But it is a fact of life that differences in sensibility and skill exist, and persist, in many teams. And not every team member can be expected to be familiar enough with every part of the code base to preserve its integrity as it evolves.

The upshot is that mechanisms are needed to allow team members with different sensibilities and different levels of skill to work with confidence on pieces of code that they are not necessarily intimate with, while preserving the integrity of those pieces of code, as conceptualized by the team members who created them, and who have invested energy and craftsmanship to perfect them to their current state.

One mechanism to prevent code degradation is what I call code stewardship: having each module be looked after by a single steward, even as all team members are allowed to contribute to that module. The steward is the custodian of the integrity of a module. He maintains intimate knowledge of the module. But he does not necessarily work at all times on just the modules he stewards. The same developer is at the same time steward to some modules, and developer of features touching modules stewarded by others.

Stewardship is a temporary privilege delegated by the team to a volunteer for each module, generally someone who has worked in a sufficiently focused manner on a particular module. The steward serves the team, which retains community ownership of the code base. Stewardship is rotated every few quarters to spread knowledge, and to bring fresh ideas to bear on each module.

It is important to have just one person steward each module. Accountability for the integrity of that module then falls squarely on that one person.

How do we practice stewardship with minimum ceremony? The key is informal advice and consent throughout the development process. Developers pull advice and consent from stewards on a regular basis in the process of developing features impacting different modules.

Code stewardship requires that before checking a change to a module into the production branch, the code be subjected to the advice and consent of that module’s steward. It would be normal and expected for such advice and consent to result in significant refactoring, unless, of course, the steward was kept in the loop as the change was considered and developed.

Stewards need flexibility in their schedules so that they can quickly respond to requests for advice and consent. And developers need to anticipate the need for advice and consent and pro-actively request pair time with stewards.

To enhance the process of communication between the feature developers and the stewards, it is useful to give stewards visibility into actual code changes in their modules, as these changes are being developed, and before the final checkin to the production branch. The changes may be shared by using provisional code branches, with automatic notification of changes to corresponding stewards. Provisional code sharing allows the steward to reflect on pending changes and to research issues and alternatives in his own time. This type of off-line communication augments, but in no way replaces, face-to-face advice and consent sessions.

Finally a trivial one-line change should never require ceremony in a small team. Just check it in to the production branch, and have the steward be automatically notified.

In summary: It is the prerogative of each developer to be able to work in each module, subject to code stewardship. Therefore, developers are expected to pull advice and consent from stewards. It is the prerogative of the stewards (and ultimately the architect) to protect the integrity of the code base. Therefore the stewards and the architect get veto power over production code. Veto power is used judiciously and sparingly.

© Copyright 2006 Bolour Computing.