If a software development organization needs to put check-in policies in place, then there are some other fundamental problems that are going on within the organization. Check-in policies are just simply a way to mask the symptoms. Let me clarify by citing some common check-in policies and why I think they hide other problems.

A check-in policy for unit tests indicates that the entire team has not bought into the value of unit testing. If they had, then the unit tests would be created and committed as part of the check in process already. No policy would be needed to enforce this. If you have developers that have not bought into this, a policy isnt the right answer. Rather, the individual needs to be coached on the benefits of the unit tests. If after repeated attempts at coaching you find that an individual still does not commit unit tests as part of the check-in process, then personnel action may need to be taken to remove the person from the team. A team, after all, is only as strong as its weakest link.

Check-in policies that require code that is committed be tied to a specific work item sends a message to the team that they are not trusted to execute on the work that they are supposed to be doing. In an agile environment, the entire team should be working together towards a common goal. If you find that this is not happening, the offending team members need to be coached to help them understand the implications of not working together to help the team achieve its goals. Again, if after repeated coaching attempts this does not resolve the problem, then personnel action may need to be taken to remove that person from the team.

Check-in policies for code reviews are ridiculous. The implication with this policy is that people are not working together and developing code in a silo. Not only are they developing in a silo, but there’s concern over whether or not their code is any good. Other agile practices, such as unit testing and pair programming, should go a long way towards eliminating the need for code reviews. Mandating that someone has to put who reviewed their code prior to checking it in though is not the answer. The team should collectively be responsible for delivering a high quality system, and everyone on the team should be responsible for all aspects of the codebase. Forcing this “collaboration” means that the teams are not working effectively together and the manager of the team should look for ways to increase team communication.

I know that there are strong opinions on these items both ways and I am certainly hoping for discussion on this.