Check-in policies signify a lack of trust
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.
You make some good points. I do think that check-in policies should be override-able in all cases. You never know.
In general, I believe that rules are used in place of trust. It turns out that sometimes this is necessary because we work with human beings.
1. Policies simply remind us of best practice when we might be in a hurry. The reason someone thought of putting a policy in place in the first place is to prevent oversight.
2. A unit test policy can help prevent the build being broken. Yes, I know we like to all think we’ll do it perfectly every time, but this isn’t my experience. We all make mistakes.
3. Check in policies provide an audit trail and in a world of SOX compliance and FDA regulation it is sometimes a matter of liability that such a trail exist.
4. It is not uncommon to have many different opinions and definitions of “correct” within a team. Although we can all agree that it is optimal for people to simply be professional about their work, many code contributing developers simply are not behaving this way. Check in policy is one way a team can police its own quality when some members aren’t playing well with others. Is this a personnel issue? Yes. I would much rather find that issue earlier than later and a check in policy can help ferret it out.
5. Tying a check in to a work item isn’t crazy, but it is overhead. Sometimes this overhead is necessary to communicate clearly back to other business people. This type of policy is really focused on auditing as cited above.
@david: As always, you do bring good points to the conversation.
Wouldnt a unit test check-in policy that discourages the build from being broken be the same as developers taking an active part in fixing the build if it breaks? A build is going to execute regardless. The time to feedback is the same. My thought on the comment was a policy that would not allow a check-in if there were no unit tests, not whether they failed. A failing unit test will fail a build. Period.
Point made on SOX compliance and FDA regulations. However, for most organizations this probably is not relevant.
Tying a check-in to a work item is certainly overhead. However, if this level of detail is what is needed to communicate back to the business folks, I suspect that there are additional issues at play. Perhaps the business is too concerned by implementation, rather than by feature. The product owner/consumer should know and care about what was done, not how and in what changeset it was completed in. Right?
Your objections seem rooted in the “policy implies a lack of trust” issue I mentioned. I don’t disagree at all.
I guess what I am saying is that there are unfortunate circumstances under which trust needs to be rebuilt, or initiated, or confirmed. Work items can be a tool to help gain that trust and to enforce good habits.
I also see some value in the idea of policy as a guidance principle. Not law, but a good prescription, thus the ability to override the policy is a must.
I guess we are essentially agreeing on what they are and what they do for us. I just don’t feel as strongly that they “policy” is a bad thing.
Maybe I’m just frustrated that Bush doesn’t have check-in rules for foreign policy. :)
You’re right by saying that we agree on what they are and what they do for us. However, I would much rather focus on teaching the value behind the proposed policy instead of enforcing a new policy itself.
