The common practice during coding is the developers pick up their own modules, create their own programs and kind of claim ownership to that code.  Meaning when there is an issue during integration and the problem has been identified that it is due to a logic error in code written by Developer A, and then the usual practice is developer A needs to be there to fix it.  Another point in normal case of development is, developers stick on to their code, meaning they do not look at anyone else’s code and take ownership in refining it or correcting any mistakes if there are any. Hence within the development team if developers work in silo then it creates more integration issues and end up in developers pointing fingers at each other for mistakes.

In a collective code ownership environment all the developers take ownership of the entire code.  There is no defined rule as only developer A should work on or fix a particular program.  All the developers keep a watch on all the programs, go through each and every program and have an understanding of what it does. And at any point of time any developer could correct or refine a code written by any other developer.  And if code version control system is in place, it would anyway keep track of a version modified by each developer.  Collective code ownership is a feature of XP (Extreme Programming) where there is no disparate teams, but a “whole team” for the project.