Alternative to Code Stewardship.
Extreme Programming considers code to belong to the project, not to an individual engineer. As engineers develop required functionality, they may browse into and modify any class. They are responsible for keeping all the Unit Tests running (and writing new ones for new functionality). They take on the same integrity-preserving duties as the class owner in a Code Ownership situation.
Working in this mode lets a responsible team move quickly to add new functionality while keeping responsibility in the right objects. Code Ownership creates dependencies and bottlenecks when implementing User Stories. We avoid code ownership, because it conflicts with commitment from the Planning Game. ("Code is nothing, stories are everything!")
The ability to make this work requires at least:
all engineers use the same Coding Standards;
code management tools to detect and resolve conflicts (CVS!);
a comprehensive suite of Unit Tests to ensure quality;
powerful browsing and Refactoring Tools to find references to old methods and replace them with the new;
Continuous Integration (or nearly that) so that conflicts are rare (also CVS).
Okay, this is where I see the scaling difficulties coming in. Collective ownership of anything doesn't scale. If Bill and Ted own a radio, and Bill wants to listen to one station while Ted wants to listen to another, they need some system for resolving their difference.
In software, it's easy to clone a radio. Bill can listen to what he wants and Ted can listen to what he wants. But if Bill and Ted are trying to use their radio programs as input to a design decision (say, what kind of guitars to buy for use in Wyld Stallyns ... in software, say, what kind of GUI to build, or what database product to use) then you have trouble brewing. Multiply the situation by 100 developers and a year-long project full of crucial decisions, and you have a Tragedy Of The Commons.
So there are a number of ways of resolving this:
keep the project small. You don't need 100 developers; you need 10 good ones. Or better, 3 good ones. If you can't do that ...
decompose the requirements onto teams, each of which has internal Collective Code Ownership. This works great so long as the problem domain is well understood. But where it's not, the left hand and the right hand have a habit of wrong-footing each other; interfaces become bones of contention; politics occurs; management takes an interest so you have to ...
define a project hierarchy. Plan release-schedules and document analyses. Collective Code Ownership gets buried under an avalanche of memos, meetings and managers.
So this last bit is where I think a Stone Society could be useful. Make interface alternatives, tool purchasing, human-resourcing, standards and design decisions subject to Auction. Let development groups form and unform naturally as Sub-Societies. Use Services to fund internal infrastructure projects. Replace politics with a free market.
-- Peter Merel
You think an unusual form of democratic voting will eliminate politics? -- Jeff Grigg
Consider Code Stewardship. It works well, and with low overhead. -- Dave Smith
Contrary to what Peter maintains, decomposing into subsystems and practicing Collective Code Ownership inside the subteams can work quite well. We work with a large System and four different labs on the same project (~30 developers). Subsystem integration is done once a week. If we have to make a change to some part of the system in order to implement a feature, we request the change from the other team. Most of the time, the change can be done without breaking the interface between the subsystems. In that case, we postpone our work to the next build. If the change has to be done NOW or the change is breaking, we get the code changes before the next build and integrate it into our local copy of the other team's code. If we make a mistake and the build breaks at integration time, we have to fix it then. This almost never happens. The team leaders negotiate which changes are done for a particular build if some conflict arises. A published work plan keeps everyone informed when to expect some change they require. The whole thing sounds complicated, but in practice it most often amounts to writing an email ("can I have this API in the next build?" "Yeah, sure"). -- Thomas Maeder
Thrashing can occur by conflicting refactoring efforts. People can get upset with the changes.
The constant rotation of pairs keeps everyone in touch and reduces ruffled feathers. XP teams have strict Coding Standards, so refactoring back and forth won't happen. I've never seen team players thrashing the code.
One of the reasons communism failed is because there is no concept of ownership and therefore less motivation for or no pride in one's work.
Please don't stretch this one too far. Collective ownership works because the group is smallish and they really do own the code - not some elite on their behalf.
I was thinking about Collective Code Ownership a little while, and I wonder: If I don't like doing GUI, but I'm really good at the other tiers, should I be rotated into GUI pairs anyway? My gut instinct is to say, "No", with a caveat. There may be grotty parts of the system that everyone fears working on. In this case, I'd imagine the group should encourage pairs to bite the bullet and do it anyway, and then the next time a grotty issue came up, the volunteers would be free from the responsibility of having to work on it. -- John Duncan
Within XP problem is solved that Programmer Chooses Tasks.
Kent The Beck writes in Smalltalk Best Practice Patterns (p.14) that "The next bottleneck in software engineering is human communication. When we say that 70 percent of the development budget is spent on maintenance, we mean that the poor maintainers have to wade through piles of documentation and code to discover the intent [emphasis added] of the original programmer. The advent of widespread reuse exacerbates the problem. No longer is one maintainer the audience for one developer. Hundreds, thousands, or hundreds of thousands of elaborators are trying to understand the intent of an abstractor [emphasis added]."
Fred Brooks writes in The Mythical Man Month (p.42) that he "will contend that conceptual integrity is the most important consideration in system design."
So I have a question for the Collective Code Ownership advocates. How, in a Collective Code Ownership scenario, is Conceptual Integrity preserved? How is it ensured that elaborators working on classes created by an initial abstractor understand the intent of that abstractor? Is it ensured by reliance on shared understanding of, and commitment to, a System Metaphor and some coding standards? Is Conceptual Integrity subordinate to the refactoring motivations of the day?
The reason I ask is because preservation of Conceptual Integrity is usually presented as one of the arguments for Code Ownership. If I remember right, the Envy Developer manuals even presented this argument as rationale for some of the philosophical decisions evident in the tool's design. IMHO Code Stewardship, with some kind of apprenticing of future elaborators to original abstractors (if possible), may be the solution that balances the forces. Thoughts? -- Randy Stafford
I would argue that Conceptual Integrity is independent of Code Ownership. Regardless of how you divide up the code for development, everyone on the team, now and in the future, needs to have a common understanding of the purpose of the project and approaches being used. Tying together individual modules, each with their own "Conceptual Integrity" won't do it. Everyone needs to be in agreement across the project. -- Wayne Mack
In our extreme lab, we do use collective code ownership. Sitting in the same room eliminates the communication delay between potentially competing factions for a piece of code, and speeds delivery of modifications. We rotate pairs purposely, and while the methodology says that the developers choose the tasks, occasionally we throw in the requirement that "For today, you must choose a task involving the part of the system you know the least about." We find that this avoids weak spots among the team quite nicely, and we get no "information sinks" because one person concentrates on a particular aspect of the application. -- Andrew Chronister
-- Collective code ownership sometimes is just a code word phrase for management saying that you can be tossed out at any time. ie: Someone else knows what your doing, and if you don't toe the line, we can easily replace you.
Code ownership also ignores the fact that programmers have different skills. Getting the internet wizard to do the graphics is silly. And vice versa. Surround me with other good programmer's, and code sharing is as natural as breathing. Surround me with idiots, politicians, or the owner's brain-dead nephew, and I'm going to protect the tricky bits, not out of ego, but because I don't want their paws mucking around and destroying things. 'Last Project Failed' doesn't look good on my resume.
Another thing, management then figures that if the old pro is gone for a few days, the junior programmer can just jump into his code and keep going. This just doesn't work.
3 or 4 guys, Collective Code Ownership works. If they all depend on the venture for their bread and butter, even better. But get more than 1 manager and 7+ programmers, and it's all just another methodology.
How can you all work together in the same room? Again, 3 or 4 guys that get along, have known each other for some time, or instantly 'hit it off', it works. Get 12 guys thrown together, someone's going to start the politics. The noise is unbearably when you're trying to get into the zone.
Collective Code Ownership sounds almost Marxist. GOOD programmers are craftsmen. They deserve some respect for their individual skills and effort. Linus keeps the kernel to himself.
And let's think about this for a minute. With everyone working on everything, there is No Ultimate Responsibility. Passing the buck runs rampant.
"I thought HE was going to fix that."
"Oh, that wasn't me who screwed that up" and now the major client is suing."
I've seen a lot of methodologies come and go. If it were possible to codify up the knowledge of a good programmer, someone would have written it up into a piece of software called 'Programmer 2000' and we'd all be out of work.
-- An old programmer
From what I read in Extreme Programming Applied, Collective Code Ownership doesn't mean No Code Ownership. Therefore, if someone breaks the code, it's his responsibility to fix it. And he can't commit change until it passes Unit Test.
Extreme Programming relies on the TEAM concept. A team is not a group. De Marco perfectly describes what a team is. So I believe that collective code ownership works very well in a team and does not work in a simple group. Naturally, a team cannot be created in a group exceeding 7-9 members; it cannot be created if the group contains a critical number of morons or idiots. It cannot be created if members are physically separated. Peopleware contains a full list of reasons that prevent a team "gelling". No team - no collective code ownership, and I believe no Extreme Project.
Regarding responsibility - team owns responsibility. This is not "I thought HE was going to fix that." It is "This is my fault because I did not make sure we fixed everything we had to".
-- Roman Eremin
See also The Cathedral And The Bazaar, Just Stop Caring
See original on c2.com 