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. :)

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?

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.