Code Ownership – who owns what?

I was involved in an interesting debate on Twitter last week.  Someone complained about having to fix bugs in another developer’s code (unfortunately I can’t find the original mention) and I made the following response.

I don’t buy into this idea of a bug being in a specific developer’s ‘domain’ – I think all developers should own all parts of the codebase

This sparked quite a debate and I was even involved in a conversation on Google wave.  (By the way, Google wave kept crashing on me – I am now officially of the opinion that Google wave sucks)

Should I really fix your bugs?

First things first – I’m not saying that you should be responsible for fixing bugs in my code.

I would prefer if we could move in a direction where the definition of ‘my code’ gets a little muddled.  Let me explain.  I have had the excruciating pain privilege of working in a codebase where large sections or modules were developed by single developers – all queries, enhancements and bugs relating to those section would be handled by the developer responsible for the original code.

The main problem here is that developers don’t stick around forever.  Key person dependency is a real risk and will come back to haunt you at some stage.  Even if you have an agreement in place where developers must give a few months notice before they leave there is still no way that they can disseminate 2 or 3 years worth of knowledge in this time.  (Keep in mind that developers are not immune to getting hit by a bus either)  Even if you recognize this risk and try to ensure that 2 developers are responsible for every module you’re still not safe – developers usually tend to leave in groups.  If your star developer departs some of their colleagues might find that the opportunity for learning has decreased and start looking for new employment.

So what should we do?

Right – so how do we achieve this?

The first technique I would recommend for eliminating this ‘your code’ mentality is regular code reviews.  My definition of a code review is for the entire development team to get together and have a look at code that is either bad (technical debt), new (everyone needs to get used to it) or exemplary (this is how we should be doing stuff).  The idea is not to get all fuming and defend your code or attack your colleagues – we should simply try and understand each other’s code and learn from it.  This is pretty easy to implement (your managers probably won’t mind if you meet for 2 hours each week on a Friday afternoon) and usually turns out to be a lot of fun.

The second technique is pair programming.  This one is more difficult to implement (and requires some experience to get right) but the benefits are much greater as well.  You will probably need to get approval from your managers for this one – “What? Two developers doing the work of one? Are you crazy?” – but don’t let this discourage you.  I haven’t met a developer who has really seen the benefits of pair programming and not liked it – the challenge is to get past the initial phase where everyone wants it to suck.

Final thought

There are quite a few techniques for eliminating this type of risk – code reviews and pair programming are simply the 2 that I usually promote.  I think the main idea is to always keep in mind that no one person owns any single part of the codebase – developers come and go but the code has to outlast us all.

Happy coding.

Tags: PatternsPractices

  1. Tim says:

    Great post, Jaco.

    I started at a new company a few months ago and I really appreciate their "code retrospective" at the end of each sprint. It is a two or three hour meeting where developers highlight good, new, and poor code, and it goes a long way to shared ownership.

  2. Jaco Pretorius says:

    Thanks Tim – I think the most important concept here is that we should all start to realize that we all have ownership of the codebase. Code retrospectives are another great way of helping to accomplish this.

  3. Paulo says:

    I agree to most of your post, but you should think a bit more before forming such opinion about Google Wave, just because it is a preview, it´s not even beta. People who have access to it are meant to help in the development by testing and giving sugestions, I think you should consider yourself a volunteer tester, not an end user.
    I saw someone saying Google Wave is bad because a person can not handle so much information at the same time. I think this is a valid argument, but crashes should be considered normal at this phase.
    Sorry if my english is bad.

  4. Jaco Pretorius says:

    Thanks Paulo – you're right – I got annoyed with Google Wave because I wanted to participate in the conversation but it simply kept crashing. I think the main argument against Google Wave is that you can respond to something someone said 10 minutes ago – but nobody is able to see your response if it's off-screen. But this is still a beta – it can only get better.