In reading up on programming practices and ideals, I have stumbled across a concept called “Collective Code Ownership”. This essentially means that *any developer* can fix bugs or write any new feature in *any project*. Bug fixing and project development should not be limited to the person that wrote the code in the first place. This introduces both advantages and disadvantages in to project management.
The Concept
The concept behind this is simple. Every developer can be responsible for the code in any project. As mentioned above, this means that bug fixes can be made by any developer, and new features can be developed by any developer. Here’s wikipedia’s current take on the matter:
Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.
The Advantages
In my opinion this introduces the following advantages.
- If a member of your development team is immersed in an important project and needs to be allowed to “get in the zone” and work interruption free, then if code they have written is deemed to be broken, any other member of the development team can fix the problem.
- This increases exposure of application code. The more developers that have seen code and got their head around the way it works, the better! When the developer that wrote the code leaves, it would be helpful to have other people who have at least seen the code and knows that it exists!
- Fresh pairs of eyes can foresee other problems with the code. Imagine constructing a delete query using a function called constructInClause, which is passed an array. This will return an SQL IN() clause statement. “Hang on a minute, what if the function constructInClause returns an empty string? Won’t that delete everything from the database?” – better to spot this before rather than after the bug is exposed.
The Disadvantages
With every new approach comes disadvantages alongside the advantages. Unfortunately, I do see a couple with this one:
- Allowing other developers to fix bugs and modify code can mean that they will not necessarily bear in mind the full knock on effects of a change. Dependencies on code working a certain way are commonplace – even if not ideal – in web based applications. (Note: Unit Testing could probably avoid this situation!)
- There is a danger of one person in the office becoming the “bug fix person”. Not many developers enjoy fixing bugs all day, so in my view it would be important to try to make sure that responsibility for fixing bugs is shared equally between the development team.
Will I be encouraging the company I work for to encourage collective code ownership?
Probably, yes! It seems like a very sensible idea, especially considering that at times interruption to fix bugs is really quite infuriating! If the bug fixing could be assigned to the “most interruptable” developer at any one time, I’m sure that productivity and developer mood would both be improved.
