One of the tenets of agile is a sense of “Collective Code Ownership”, that is, that everyone on the team owns the code.
The “traditional” model is for people to specialize in different areas of the code and to rely on those people for their respective parts of the code. The way this manifests itself is that at most 1 or 2 people understand the harder parts of the code and everyone else are “generalists”. OK across the code base but not well versed in any particular area.
Fred Brooks, in The Mythical Man Month, spoke of a surgical team, where one person acted as the “surgeon” (doing the work) and everyone else supported the surgeon with whatever they needed.
Large and complex systems will invariably have people specialized in sections of that system, and those people will necessarily be harder to replace should they win the lottery.
agile methodologies (like Scrum and XP) try to solve this through collective code ownership.
Projects often rely on ‘fast’ work (when have you been part of a software project that was released on time, budget, and original scope?) and that has a natural tension against collective code ownership.
Developers work faster in areas of the code they understand, and specialization helps that. Developers also hate to be pigeon-holed.
So what do we do? Push code ownership for the sake of delivery? Or Push collective ownership for the sake of the bus factor?
Why Not Both?
Encourage developers to learn and specialize, and also encourage them to trade off and teach each other about what they know. This can take the form of documentation, brown-bag sessions, or a post standup teardown of a problem they’re having.