What are good ways to handle ownership in a common code base?

Question

We are in a project with a dozen members, working on some fairly cutting edge stuff, and want to work out a good approach to code ownership. On the one hand you always want at least two people familiar with any area ("common code ownership"), but there are countervailing advantages to having a single person in charge of an area to give it a consistent vision and to minimize the chance of one person inserting code that violates the assumptions of another person ("individual code ownership").

How have you seen this tension successfully resolved in the past? Is pure pair programming the only way to combine the advantages of common code ownership with individual code ownership? Does the "chief programmer team" concept work out?

Note: this question and this one, are related, but focused on ironing out interpersonal difficulties (eg, a territorial project guru) on the road to common code ownership. Let's assume for this question that the team gets along well together and wants to find the most effective approach.

Edit: Also see this question, again focused on difficult project members.

Edit: To clarify, I agree that the team (company) owns the code here, and am assuming the team gets along well without interpersonal difficulties. We've set up a Wiki, a Hudson continuous build server, and unit testing to make it easier to shift people around. What I'm after in this question is the right balance between generalization (all people work on all the code) and specialization (one person is responsible for one area, and there is no overlap). It's definitely bad to have pure specialization, but in complex projects with very different sub-areas some specialization seems inevitable.

Answer 1

You could divide the software into [3 to 4] components, developed by teams of 3 to 4 developers each. You can assign a different feature to each developer, but the fact that each developer is developing within the same software component (package, assembly, library, call it what you will) as the developer on their team will give each them insight into at least the internal architecture of that component.

Also, peer code reviews.

Answer 2

the team - i.e., everyone - owns the code.

• The unit tests keep people from breaking things.
• Peer reviews help maintain a consistent vision/architecture.

The above helps prevent prima-donnas, fiefdoms, high bus factors, and a host of other mine-mine-mine issues. It also encourages information sharing and a bunch of other fuzzy-bunny touchy-feely stuff ;-)

In reality, the company owns the code, it is the team's responsibility to shepherd it without flocking it up

;-)

Answer 3

"chief programmer team" concept never worked out, as programmers do not want to be "peons" doing a dirty work while one of their peers is doing all the interesting stuff. Even in cases where there is one genious, if you give this guy all the important (usually interesting as well) things, the rest of the team tend to be lower than average. The reason is simple, good people will not stay cleaning code of somebody else.

Answer 4

Colloquial answer:

1. Collaborative development practices such as pair programming and code reviews.
2. Posting visual feedback can be very good at getting focused effort on a particular goal. That's why you see everyone doing the giant thermometer posters for team-donation efforts.
3. Proper modularization.
4. Good developer testing habits.

Opinionated answer:

I think it's easier to answer the contrapositive of your question, which I see as: "what are barriers to anyone taking ownership of any piece of code?" It helps to think of things in this way and make it more about removing roadblocks and solving problems than "what am I not doing that I could be doing?"

My first response is fear. Fear of what?

Fear of Breaking Something That Works

This has a lot to do with "legacy code." Developers are scared to death of touching legacy code. They'd rather work around it than risk touching it and breaking it. Why? If you break something, it becomes your problem. (See also: Problem Sovling Flowsheet)

Michael Feathers, author of Working Effectively with Legacy Code, says legacy code is untested code. Good testing habits free you from the shackles of worrying about breaking something. If you break it, you'll know about it before anyone else and have the good sense not to commit it. If you have time to figure out what was wrong with your approach, you'll likely ask for help.

Fear of others

As to the question of specialization, I think people naturally gravitate toward problems they'd like to work on, and that's fine. Modularization will help with this by hiding complexity. But it becomes a problem when people are afraid to dive deep on a problem because they're scared of someone else's code, or they don't trust anyone else to modify their code. This is the easiest to fix, though. Pairing people up usually works really well.

Fear of the unknown / failure

This is related to code ownership because certain people are reluctant to work on certain problems. Tests help with this, too. You can point someone to unit tests when encouraging them to reuse or work on a piece of code. Some common remedies this problem:

• Create a prototype to learn
• Timebox developing a "throwaway" solution to learn
• Use Spikes
• Use Tracer Bullets

Etc.

And so on, I'm sure there are a lot more things to think of, especially when you start thinking about your specific scenario. (check out Nathaniel Talbott's "Fear of Programming" if this is at all interesting to you.)