The last couple of places that I have worked also had a number of sensible rules in place to ensure quality. E.g.
- never commit directly to master, always create a PR from a branch
- always make sure tests are green before merging
- branches should be traceable to JIRA IDs
- checklists in JIRA
- etc.
Apart from the checklists, which people tend to skip, most of it makes sense. Running everything through a pull request is a good example of something which slows down the process but which is still worthwhile IMHO.
That being said, I really dislike when too many of these constraints are enforced by the technology. In coding, like in driving a car, there are times when common sense overrides traffic rules. Sometimes, even in the best and most diligent teams, the build server turns red. In that situation you just need to quench the fire ASAP to keep it from spreading. You don't want to create a task in JIRA, you don't want to create a branch, you don't want to involve your colleagues in pull requests, and you don't want to wait for a hour for unit tests to pass. You just want to apply the simple fix or revert the commit.
And that's why I prefer moderate social pressure over some algorithm enforcing stuff. A good team will know why the rules are there, they'll be professional enough to stick to them 99% of the time, and they'll also be professional enough to break them the last 1% of the time.
> * In coding, like in driving a car, there are times when common sense overrides traffic rules.*
Definitely. It's possible to override any of these things in our setup. Most of them can be overridden by the person doing the coding, but a few of them require the team leader's approval.
If the rules are overridden, it's logged in our issue-tracking system, and we can discuss whether it makes sense to keep the rule or get rid of it.
Apart from the checklists, which people tend to skip, most of it makes sense. Running everything through a pull request is a good example of something which slows down the process but which is still worthwhile IMHO.
That being said, I really dislike when too many of these constraints are enforced by the technology. In coding, like in driving a car, there are times when common sense overrides traffic rules. Sometimes, even in the best and most diligent teams, the build server turns red. In that situation you just need to quench the fire ASAP to keep it from spreading. You don't want to create a task in JIRA, you don't want to create a branch, you don't want to involve your colleagues in pull requests, and you don't want to wait for a hour for unit tests to pass. You just want to apply the simple fix or revert the commit.
And that's why I prefer moderate social pressure over some algorithm enforcing stuff. A good team will know why the rules are there, they'll be professional enough to stick to them 99% of the time, and they'll also be professional enough to break them the last 1% of the time.