Who's the owner? Shared code vs. code ownership

June 23, 2009 by Mendelt Siebenga

I think it's widely recognized that shared code is important in agile teams. It's an effective way to streamline your development process, making your teams more flexible and productive. Transitioning from code-ownership to shared code can be hard. Lets compare the two, look at the problems in transitioning from one to the other and see how we can ease this transition.

Shared code is only a corollary practice in extreme programming but most agile teams I've seen implement it successfully. Many other teams are still in a situation where team members have what I call code ownership, the code base is divided into parts that can only be edited by certain persons or groups within the team. Usually the code is divided along lines of expertise, for example database-professionals develop the database, the back-end and domain logic is developed by one or more experts, and interaction designers and UI developers are responsible for the user interface. The reasons for this division are usually efficiency, people work on the parts of the code that fit their skill set, and responsibility, when something is wrong it's easy to find the guilty party by looking at what piece of the code failed.

Why Share?
In practice things work a bit different.
Code ownership is actually not very efficient, most non-trivial features will take changes in most of the layers in the application. This will create unnecessary dependencies between team members and unnecessary delays.
Having people take responsibility for pieces of code isn't very useful either. Eventually implemented features are what count. I have seen many situations where no-one took responsibility for a defect in a feature because of code ownership. The database-guy blamed the back-end guy, the back-end guy blamed the UI team etc.
Code ownership is also risky. Specialization like that will create knowledge silo's in your team. If the database guy gets hit by a bus who will take his place?

So what's keeping you?
So if shared code is the way to go, how do we get there? Is just telling everyone to edit any piece of code enough? Of course it's not that easy. When you remove safeguards you'll have to replace them with other safeguards, there are a couple of things that need to be in place to enable shared code, responsibility and trust

Responsibilty
We already looked at responsibility, making individuals responsible for parts of the code is not the solution. In teams with shared code the whole team is responsible for the whole code base. But if more than one person is responsible then effectively no-one has responsibility.
But in parts of the code base aren't that important to our clients. Working features are, user-stories are. Most agile methodologies let people take responsibility for implementing features or user-stories at the start of an iteration. Dividing responsibilities along the same lines as the actual deliverables results in less finger-pointing and more cooperation.

Trust
In many cases developers themselves are opposed to the idea that any other team member can change the code they worked on at any time. Team-members need to trust each other in order for shared code to work, they need to be sure that every time a team member edits some piece of code the code will be better than before the edit. This means the team actually needs to agree on what 'better' is. So there need to be coding standards. It's also good to have a code-review process in place. Of course instant code-review in the form of pair-programming would be even better. A good version control system is a good safety net in case things do go wrong. Practices to get quick feedback on code quality like TDD and continuous integration also help.

Shared code is an important agile practice but getting there takes some effort. Getting rid of code ownership without a support structure can cause problems agile practices in order to guarantee consistent quality and to work in a responsible way. Agile practices like TDD, continuous integration and pair programming help keep quality high and responsibiltiy needs to shift from code to features in order to be successful.

Permalink