We are all responsible for high quality code. There is a metric for imposed risk by concentrating knowledge in just a few people's heads -- it's called the truck number. How many people can get hit by a truck before the project suffers irreparable harm? [Shore & Warden 2007]
Some developers consider this job security and, if you're in a company or state of mind where this is your sentiment, I sympathize with you. But it shouldn't be the case!
I often tell my clients that I only hire people that love what they do. My belief is that if you love what you do then your exuberance will be infectious and thus pollute the groundwater. You simply spend too many hours of your life "working" so why be unhappy while doing it? Honestly, if you can't stand your job, then you need to take action. That said...
As a team, we can't operate at 100% efficiency when we do not have redundancy. Things come up... Folks get sick, have emergencies, retire, go on vacations, you get the picture. Your project should not suffer when a team member can't make the game.
The concept of Collective Code Ownership (CCO) extends to all areas of development. When only one developer knows how to tweak the installer, it's time to refactor or educate.
CCO also applies to bug fixes... I know that I personally don't enjoy rooting around through broken code, especially when it's not my own! However, it's different when you weave it into your company culture. I subscribe to the old boyscout motto: Try and leave this world better than you found it.
Ideally, we don't have bugs because we're using TDD. But, let's be honest, we don't live in an ideal world and mistakes happen. I know that some of you would accuse me of rose color glasses syndrome but I assure you that this is not just Utopian dribble. It really works. That said, if you spend more than 15 minutes digging around and can't find the problem, it's probably time to rollback to the last working build.
[With CCO] No one person can be the bottleneck for change. [extremeprogramming.org]
Collective code ownership requires letting go of a little bit of ego. Rather than taking pride in your code, take pride in your team's code. [Shore & Warden 2007]
CCO is a tool. If it doesn't work for you, don't use it. My vote, always evolve. Don't scoff at a good idea because you'll never know if you don't at least try.