Moreover, it also helps filter "bad apples" out of your development team. In an environment where group members feel a strong investment in code quality, any developer who does not care about the code will alienate himself from the group. Most group developers will soon become frustrated with someone who constantly introduces problems into the code and will try to help this developer improve. If he does improve, the group is stronger; if he does not, group conflict will generally lead him to leave.

Code ownership should be balanced by what is called "egoless programming." The point of egoless programming is that the group owns the code; each developer takes responsibility for the code, but each developer should not take criticism of the code he wrote as a personal attack. If a developer is overly sensitive to constructive criticism, he probably won't grow as much or as rapidly as developers who can handle it. If you find that you have a developer who takes this type of criticism personally, you should sit down with him and explain that you are trying to help him improve his abilities and the quality of the code.

Code reviews

The best way to ensure that each group member understands the importance of preserving code integrity is to implement practices that help ensure and maintain quality.

One of the most important practices is properly implementing code reviews. The purpose of code reviews is to exchange ideas about how the code is written and to establish a standard group interpretation of the code. The most effective code reviews focus on tasks that can't be automated.