CodeOwnership

team organization · extreme programming · process theory

tags:

There are various schemes of Code Ownership that I've come across. I put them into three broad categories:

Of the three the one I really don't like is strong code ownership. There are just too many situations where something you need to do needs changes to other people's code. Persuading them to make the change and waiting for the change often takes so long that it leads to delays and deeper problems, this is particularly galling when the change is a simple one.

A good example of a simple change that causes trouble is renaming a public method. Modern refactoring tools can do this safely with extensively used public methods. But this violates code ownership if you cross a module boundary. Essentially you've turned all interfaces between developers into PublishedInterfaces, with all the attendant overheads to change.

Even worse is when you want an implementation change, but because you can't get it quickly enough you make a copy of the foreign code into your module, call your copy of the code and make the change. Of course you intend to sort out the mess later.

Weak code ownership is a good way to mitigate these kinds of problems. People can make changes freely, the code owner just has to keep an eye on things.

The choice between weak and collective ownership has more to do with the social dynamics of the team. Both seem to work, and fail, equally well. Personally I prefer the dynamics of a collective code ownership team - particularly in the context of Extreme Programming.