Hacking code ownership

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.

Introducing TDD
But now things were different, no-one touched code. I was free to start writing unit-tests. At first this wasn’t easy. UI’s are never easy to test. But I started slowly refactoring all the screens I worked on to extract the presentation logic to separate presenter classes that I could test. Slowly my test coverage got better and slowly my code got cleaner making it easier for me to implement new features.

Introducing Pair programming
Code-ownership also created extra dependencies within the team. Changes in the code usually went right across the artificial boundaries. This created an ideal opportunity for me to introduce pair programming. If someone wanted me to implement something I’d invite them to sit behind the computer with me to help me figure out what I needed to build. I was actually kinda surprised how quickly people picked up this habit.

Because I actually had the chance to be successful with TDD and because pair programming gave me the opportunity to show this off to my team members they started picking this up. The guy responsible for the data-layer actually had been doing TDD on his personal projects but had had difficulty doing it over here because most of his code was tightly bound to the database. I helped him separate the logic he wanted to test from the pure data-access code and helped him get started using Rhino-Mocks, a .Net mocking framework.

Because my contract ended I didn’t see that project through to the end. I heard they started sharing code more when they got more comfortable with each others code through pair programming and they were experimenting with continuous integration now.

The retrospective
Lets do a project ‘retrospective’ and see what we can learn. Should or shouldn’t we get rid of code ownership? I think we should, eventually, but whenever you get rid of something you should think of the value it brings first.

In his book Working Effectively with Legacy code Michael Feathers talks about using an anti corruption layer to shield our newly written code from getting corrupted by bad design decisions made in legacy parts of our system. These layers are a temporary fix, as the old code is upgraded to new quality standards, piece by piece it slowly move and eventually become unnecessary. Sometimes we also need an anti corruption layer in our teams and ironically code ownership, a practice I criticised in my article two weeks ago, gives us the means to implement such a layer.

Another thing that surprised me here was how easy it was to get people to do agile practices when they were introduced at the right pace in the right order. ‘Refactoring’ a team to agile instead of trying to become agile in one big leap actually has helped me more often. When you take small steps and be careful to take the step that brings the most value every time acceptance is easier and faster and that will make sure people will keep on improving even when you’re gone.

4 thoughts on “Hacking code ownership”

  1. I have also found that agile practices go in more easily if they are introduced as something simple and small. Just as you have noted, do them first yourself and then introduce them to the rest of the team at the right time and in the right place.

    Getting a team to sit down and completely change their style overnight is going to spook the team, and spook management as well.

    Adopting Continuous Integration actually has been one of the easiest steps in my experience, because the whole team can see the benefits so clearly. It also takes the grunge work away from whoever plays the role of build engineer for the team.

    Once you have CI in place, then lots of other things start to fall into place – static code analysis, automated testing, automated unit-testing, etc. They all have a place to hang from because CI laid the groundwork.

  2. Have resentment or two you need to get off your chest? Stop the ranting and learn how to live – for god’s sake man, life is way too short.

  3. @Mr. Herticus
    Great observation. Adding a CI server is one of the easiest things you can do to get going introducing agile.
    Teams need time to learn to use new practices. So indeed you need to introduce them in a way that allows people to master them. In grass-roots agile implementations like the one I’m talking about this is actually easier. People will just stop listening when you go too fast. This is often more of a problem in management-driven agile implementations.
    Another thing to look at is when introducing agile step-by-step is to find the right steps every time. Doing things in the right order for that situation can speed things up.

    @anonymous
    I’m not in the habit of taking life-advice from anonymous people who leave rude comments on blogs. So I’ll pass on that. I re-read my article but still don’t see where you find the ‘resentment’. I actually had lots of fun doing the project I’m talking about here. I’m trying to share some observations I made in the past that might be useful to other people, if they’re not useful to you then you’re of course free to ignore them.

Leave a Reply

Your email address will not be published. Required fields are marked *