Category: code ownership

Hacking code ownership

July 8, 2009 by Mendelt Siebenga

Two weeks ago I wrote an article about the virtues of sharing code in teams. Just to confuse you, this week I want to tell about a situation where code ownership actually helped me introduce a couple of agile engineering practices in a team I worked with some time years ago. Here's the story. Facts, names and situations have been twisted a bit to ensure the client's privacy.

The project
When I got started on this project the team had already been working on the code for some time. They didn't have strict rules about code ownership but most developers had started on their own piece of code at the beginning of the project and had kept on working in the code they knew as the project went on. When I joined the team everyone had a well defined layer of the application to call their own. I got to work on the UI layer.

On previous assignments I had tried introducing TDD and pair programming. But I often ran into problems. Maintaining a set of tests is hard when your co-workers change your code and don't fix tests when they break. You end up spending extra time fixing the tests other people break and it's hard to convince people to do TDD when it's costing you so much work.

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.