How to revoke collective code ownership?

Question

The benefits of collective code ownership (CCO) can be tremendous. But there is a risk that it turns into "no code ownership" (NCO). In my opinion, CCO is a right a team has to earn. While going from strong code ownership (SCO) to CCO is not easy, it seems even harder to go back. First, revoking CCO has the potential to slow the team down. Second, it may be seen as a way to assign blame (aka "provide the opportunity for pride in ownership"). However, if the situation is bad enough with NCO, there is a substantial potential upside of going back. What are some of the pitfalls and tips to make it work well? Have you successfully done this?

Update: Obviously, revoking code ownership must not be called "revoking code ownership" in front of the team. As some have mentioned, this is a delicate thing and if it is to be possible at all, it needs to be messaged properly and arrived at gradually. The question is: what are some of your experiences in doing this?

Update: To provide more context, the other practices that are going on in the sample team are: pair programming, automated acceptance testing, continuous integration, and, to a small degree TLD ("test last development", as opposed to TDD).

Answer 1

CCO with TDD works great. Don't break the build, and don't break the tests, and you can alter any code necessary to get the job done.

CCO without TDD is asking for trouble

Answer 2

The problem is a very social one..

Social dynamics and personal feelings are very much entangled in the codebase, as most developers are quite proud of their work. Turning over control of their code can be a scary thing, deeply rooted in feelings of personal pride and self-worth. A few eye-opening experiences have shown me that these is basically a good thing, and despite the trouble that comes with pride and overzealousness, you wouldn't want developers to be apathetic. Of course, you want to be hiring people with healthy confidence and tolerable egos, but we're all human, and conflicts are bound to arise, even among well-meaning and good-natured people. The real challenge of transitioning from a strong code ownership to collaborative code ownership is finding a way to get past these difficulties within the team dynamic. Fostering healthy team dynamics will help the established team members feel good about turning over some control of the code.

New Talent Upsets:

When new developers come in, especially when their skill level is higher than much of the original team, tensions naturally become high, and the established developer(s) have a tendency to become defensive of their code and positions. One of the most successful tactics I've seen for making such a transition has been making sure that the veteran developers feel respected and appreciated, regardless of whether or not they treat new team members well or generally seem to deserve it. In these situations, it's always beneficial for their new code to framed in terms of an extension to the good foundation that the veterans have laid. You may be re-architecting the entire codebase, and refactoring every line of code, but it's no good for the team to make drastic re-writes into a point of focus. It's also important to make the new developers feel supported as they forge ahead, and protect both sides from stepping over the line as everyone adjusts.

Trusting Newbies:

Sometimes the veteran developers are at least as skilled as the new hires, if not moreso for their experience. But there is still a reluctance to hand over control of a product which may represent hundreds of late nights and enormous amounts of effort. If tensions can be lowered, olive branches extended, and interpersonal trust gained, then people are more willing to consider one another's ideas, consider constructive criticism, and share code ownership as a team grows. Only hire the best junior developers, and be careful not to give them more than they can handle. Pairing a good junior developer with a seasoned pro can be an incredibly productive and powerful experience for all parties.

No other way forward:

In startup companies, some of the earliest developers are sometimes fully vested, and they won't be leaving any time soon. So minimizing the damage in personal relationships is a good thing it's own right, but is also an essential ingredient for moving the company and the product forward. Once code ownership is distributed across a team, it's highly unlikely that you'll revoke it entirely (a bit of a pandora's box..). It's more about finding a good balance with the team, ideally allowing everyone to contribute and take healthy ownership of some task, project, or featureset while keeping the larger picture in mind.

Early on in my career, I had a harder time navigating these kinds of social dynamics, and had some regretful experiences. Over time, I was able to see some tense situations defused and be part of some healthy team building. It's a really great thing when this can happen, especially with minimal fallout.

Answer 3

Agile processes come with other practices that temper that risk: continuous integration, refactoring and especially pair programming.

I won't change anything before the problem actually arises. If this occurs, bring the point to the iteration retrospective, have it ackowledged by the team and let them find a mean to alleviate the problem.

Now, if your code base is very large enough or very specialized, for instance network, GUI and database, you can have specialized programmers that are only allowed to work in their area ; or you could setup a rule than one of the two programmers of the pair should be specialist - at least knowledgeable - in the code area.