I’m a big fan of having a coding style guide when working on a piece of software with a team. To be honest, I actually believe it’s an absolute must for a team to have a unified code writing style to be able to function optimally. Many software developers will agree with me, but also many will disagree, either way, it can be a pretty hot topic for a nice discussion during lunch, coffee, or maybe even while having a beer, if you’re really hardcore.

Although being very important, uniform coding style is merely a tool to ‘implement’ an underlying, more important aspect of collaborative software development, namely code ownership. That’s what I want to discuss today.

In ye olde days, I would always defend team coding style with the argument of achieving the higher goal of collective code ownership. Everybody owns all code. Everybody is allowed to change whatever part of the source base they think is necessary. Refactoring is key to keep the code base maintainable. I still believe in all of that, except for the very first thing, namely the fact that everybody should own all code. That’s just plain impossible. With a code base of say, more than 100k lines of code, you must be the smartest guy on earth to own it all. In that case, when you’re the best programmer in the world, you don’t even need a team, so you can stop reading here. However, were talking about real life here, and in real life, we cannot all be the best coders in the world. In real life, you will have a team, and you will have Bob who knows all about the network layer, Joe who is all into the GUI stuff, and then there is Collin who you need for the build and test system, and of course don’t forget about Jane, she knows a bit about everything, especially how all components are tied together.

So there you are with your utopian dream that everybody needs to own all code. Let’s take another spin at it. Is there another way to look at this issue of code ownership? Actually there is: Thanks to reading Coders at Work I’m now looking at this slightly different. Namely, we can turn it turn around: Instead of everybody owning all code we want nobody to own any code.

Nobody owning any code? So what does that mean? Well, each and every team member should be “allowed” to touch any part they want. That means that everybody has access to the whole code base, and should be able to read and understand every part. There’s where the coding style comes in to play: as a tool to facilitate team members to be able to more quickly read and understand a part of the code base that he didn’t write himself originally and is thus not yet familiar with. Another super valuable tool here is an API documentation generator. Especially together with a set of guides that prescribe how you should document your classes, methods, functions, and all other public interfaces. Next to a coding style guide, an API documentation system (such as Javadoc, Doxygen, Sphinx, etc.) is something I’d always implement in a team setting.

An important question that remains still is, if nobody owns the code, who’s responsible then? Simple: the whole team is responsible for all code. If something’s wrong anywhere, it’s the team’s responsibility to figure out who would be the best suited for solving the particular issue. Could be anyone, since everybody should be able to at least figure out what’s going on. Of course there will probably this particular person in the team that knows most about this specific part of the software where the problem occurs. Now I’m not saying he shouldn’t be the one to attack the issue, he might as well be the best person to solve it, he’ll probably be the quickest at least, I guess. However this guy could be Super Busy with some other Highly Important Things, or on vacation or whatever. With the team being responsible, the problem should be solvable by any team member.

Summarized, I’m advocating the tools to build a real team, a team that feels collectively responsible for what they are building. I believe that, in achieving this goal, the form of collective code ownership where nobody owns any part, but where you have team responsibility (but not ownership) for all code, together with tools like coding style guides and API documentation tools can be a big leap forward.