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.