Tuesday, August 18, 2009

Collective Code Ownership

Whether you're practicing agile, XP, or even waterfall, I'm a big believer in collective code ownership. Few things bother me more than another developer asking "Hey, is it okay if I modify your code?" with the exception of other developers getting angry when I modify "their" code.
The general rationale I get from non-believers is that someone changing the code may not know what they are doing and thus the code may break. I have a couple of problems with this:
1. Unit tests should be testing the code, especially if you're worried about it breaking. When any developer makes changes, if the tests are all still passing, you should be able to safely assume the code is working properly.
2. Developers generally aren't just going around changing code without knowing something about it (or at least they probably shouldn't be). And if the developer doesn't know too much about the area, they will (or should) ask someone that does know about it. In my opinion, it's definitely acceptable to have a person or people that are the points of contact for a given area of code. If you need help with it, ask them, but points of contact and code owners are very different.

Individual code ownership promotes blaming/praising individuals. While it is certainly important to know who is contributing what, a software team succeeds or fails as a whole. Sure, different people may contribute more than others, but if the product is not successful, the whole team fails. And that's really the bottom line.

No comments:

Post a Comment