Agile software development methodologies like Extreme Programming (XP) propagate collective code ownership: Every developer is allowed (and encouraged) to make changes wherever necessary. But is this really a realistic, useful approach?
The theory sounds compelling: Everybody knows their way around the code base and can work on anything. Without module owners, a potential bottleneck is eliminated and an absent programmer doesn't block progress anymore. However, as I pointed out in the comments to this article, it all depends on your team.
When It Works
Judging from my own experiences, collective code ownership needs several preconditions:
- Team members are on a similar skill level
- Programmers work carefully and trust each other
- The code base is in a good state
- Unit tests are in place to detect problematic changes
If skill levels diverge widely, more experienced programmers usually won't trust their less experienced colleagues. When code is modified, there's always the risk of breaking things (and unit tests can only go so far).
But even if the environment is suitable, true collective code ownership is hardly realistic. In practice, there are always experts who are more proficient in some areas of the code. You can make changes there, but difficult bug fixes or major new features should be coordinated with them. Otherwise you'd just waste your time or achieve less than optimal results.
In XP, pair programming provides real-time code reviews that work as a safety net. As long as pilot or co-pilot know the code they are working on, major damages won't happen that easily. However, if pair programming isn't used, a different review technique is needed to catch mistakes early on. In some critical areas (ie. performance hotspots or security related parts), it may even make sense to prohibit changes without team consent.
When It Doesn't
When skill levels or areas of expertise diverge widely, collective code ownership may not be your best bet. Experts will always achieve better results in their area and you usually don't have the time to get everyone on the team up to speed.
With the collective ownership model, "broken windows" can be fixed quickly on the fly which helps to save your code from decay. However, if your code base is in a bad shape already and you don't have a test suite in place to protect you from accidental damages, things are different. Strict code ownership will yield better results here since it's less dangerous. The code may not be pretty, but at least some parts work and there's no point in taking any risks, especially when you're in a hurry.
Strict code ownership protects quality code against mistakes from weaker programmers leading to an encapsulation of bad code in a limited number of modules (quarantine areas, cynically speaking). With this containment strategy, you can direct debugging and end-game cleanup towards those problematic modules first since bugs have a higher probability to show up there.