Code Stewardship

CodeStewardship is an alternative to CodeOwnership, emphasizing that code is the team's property, and not the sole province of any one person. A team member is granted stewardship over a piece of code. The steward has primary responsibility for the code's "care and feeding," with input and guidance from the community. The steward normally makes all changes to the code, though trusted members of the team may make changes that the steward is then responsible for vetting.

I've found that teams that adopt the position that code is owned by the team have fewer ego conflicts over code than teams that adopt single-user CodeOwnership. (My experience is with small teams in startups. Your mileage may vary.)

-- DaveSmith

The difference between this and single code owner are subtle, if not downright cosmetic. The name is different, and probably better in that it emphasizes that the programmer is responsible to the group and that his or her position is temporary. However, unless these consequent ideas are reflected elsewhere in the policy (eg reviews of stewardship by the group, periodic reassigning of stewards), I'm not sure the name alone is enough to change what actually happens. You say that only the steward can make changes, so structurally it is very similar. -- DaveHarris

The difference may seem subtle, but the behaviors generated by CodeStewardship are noticeably different from the behaviors generated by CodeOwnership. It comes down to ego and turf. Someone who believes that they own the code is, in my experience, likely to hang their ego more on the success of their component(s) than on the success of the overall product. Stewards, on the other hand, are more likely (again, in my experience-YMMV) to make decisions based on the common good, often allowing (or contributing to) changes in their code that they'd have done differently or not a all if they "owned" the code. -- DaveSmith

What problem is solved or avoided by encouraging CodeStewardship instead of CollectiveCodeOwnership?

My read on CollectiveCodeOwnership (influenced by the other XP pages) is that the two ideas are nearly identical, though CodeStewardship explicitly allows for subject matter experts (e.g., the database steward, the GuiToolkit steward) while CollectiveCodeOwnership does not. In practice, this may not be much of a difference, since developers will naturally gravitate towards their area of expertise. -- DaveSmith

Actually in XP we discourage people gravitating. We recommend switching people around so that you don't get the ego involvement and you do get cross-training. -- RonJeffries

But don't you sometimes need specialization? Building a GUI requires very different skills than building an object distribution layer or using a database. -- RussellGold

You can have two GUI experts on a team; can you have two GUI stewards? I got the impression the answer was no, that a steward was one person with sole responsibility. "Steward" to me sounds like a binary thing: you are one or you aren't; where as you can have degrees of expertise. To me it sounds like CodeStewardship is pushing in the same direction as CollectiveCodeOwnership but is still much closer to single code owner. If there's an advantage, its that being less radical it may be more acceptable to conservative programmers. -- DaveHarris

You can (and I have had) multiple stewards for the GUI. On reflection, this looked very much like CollectiveCodeOwnership. The stewardship relationship isn't binary, and does bind by degree of expertise. We kept this from degenerating into CodeOwnership by constantly reinforcing the team's ownership of the code base, and by looking for cross-training opportunities. -- DaveSmith

I like the term CodeStewardship, because it reinforces the idea of programming for others who have as great a stake in the code as the original developers. And it suggests the varied activities of coordinating software evolution: the generation and management of diffs and patches, the testing and fielding of alternate versions, the refactoring of differing versions when possible. -- ScottJohnston

I usually interpret "ownership" to mean what is described here as "stewardship." Many people seem to infer that ownership implies exclusive access; but to me it merely implies authoritative access-control: I may own a car, but I have the authority to give the keys to person's I deem trustworthy and responsible if I so choose. Similarly, I may own a piece of code but I get to choose how relaxed/restrictive I am to others who want to get their hands on it. --BradAppleton

There is a distinction I think, one that can make a difference when discussing such configuration management concepts. "ownership" brings to mind "rights", something everyone wants. "stewardship" brings to mind "responsibilities", something not so universally clamored for. -- ScottJohnston

I never knew such a disciplined enunciation of these ideas existed until now - thanks to all who have formalized these thoughts. Eight years ago I ran a data center which inherited code from other sites - we did not develop it. We HAD to adopt stewardship principles - and other XP techniques - to survive. Our rules were simple:

1) Every piece of inherited code was improved when a change was made: minimally by documenting paragraphs not previously documented, or structurally by - what I now understand to be - refactoring.

2) Every change going into production was peer-reviewed. As a supervisor my changes were subject to the same rule, and my code was reviewed by my subordinates. If you couldn't understand the changes, then rule #1 was violated, by definition.

3) Every subsystem had a primary and a secondary knowledge expert. We were our own development AND production support shop, and the business could afford no module going into production that couldn't be fixed by any available member of the team.

4) Every peer review had to be able to reproduce the test results.

5) The combination of 2, 3, and 4 meant the following: You were fair but thorough in reviewing other's code (because you might get called on to fix production exceptions), you were thorough in your own testing, and you were thorough in your documentation and documentation review since you might have to walk through this code on an emergency basis!

Our standards were borne out by the following 2 statistics:

a) We reduced time spent on fixing problems from 25% of programming time to 12%

b) We reduced time spent on fixing OUR problems from 11% to 2%

-- Andy Higgins