Collective code ownership
"We are all responsible for high quality code"
There's a metric for the risk imposed by concentrating knowledge in just a few people's head. It's called truck number. How many people can get hit by a truck before the project suffers irreparable harm?
What happens when a critical person goes on holiday, stays home with a sick child, takes a new job, or suddenly retires?
How much time will your department spend training a replacement?
Collective code ownership spreads responsibility for maintaining the code to all the programmers.
Collective code ownership is exactly what it sounds like: everyone shares responsibility for the quality of the code. No single person claims ownership over any part of the system, and anyone can make any necessary changes anywhere.
In fact, improved code quality may be the most important part of collective code ownership. Collective ownership allows everyone to fix problems they find. If you encounter duplication, unclear names, or even poorly designed code, it doesn't matter who wrote it. It's your code. Fix it!
Collective code ownership requires letting go of a little of ego. Rather than taking pride in your code, take pride in your team's code.
Rather than complaining when someone edits your code, enjoy how the code improves when you're not working on it. Rather than pushing your personal design vision, discuss design possibilities with the other programmers and agree on shared solutions.
Collective ownership requires a joint commitment from the team members to produce good code. When you see a problem, fix it. When writing new code, don't do a half-hearted job and assume somebody else will fix your mistakes. Write the best code you can.
On the other hand, collective code ownership means you don't have to be perfect. If you've produced code that works, is of reasonable quality, and you're not sure how to make it better, don't hesitate to let it go. Someone else will improve it later, if and when it needs it.
