> On the other hand, a reason can convince people, while a policy can be avoided, worked around or ignored while creating zero feelings of guilt.
Though, I'd imagine that, in many cases, adding reasons would turn a policy pamphlet into a textbook.
This seems like one of those areas where there are unavoidable tradeoffs:
* clear, concise, and rigid policies are easy to communicate and enforce, but frustrate people with better ideas.
* clear, concise, and flexible polices invite a lot of noise from people who think they know more than they do (e.g. can I use my own custom password hash I invented? It has more bits so it must be more secure.). Enforcement is also harder, since now you have to track exceptions.
* policy reasoning is harder to communicate, may never get read, and may actually discourage reading the policy.
You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception. Then all of the lazy compliant people could have their brevity, and the crackpots and geniuses would both get the explanatory text they needed.
> You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception
Very often part of the purpose of the policy is to end debate about how to handle an issue, and to get the “crackpots and geniuses” to STFU.
That's not a motivation that policy sponsors usually want in print, though.
> You could have one pamphlet with the policy, and a separate book with the reasoning, and instruct people to check the book when proposing a change or exception.
That's still a significant trade-off: putting together a book with the reasoning would be a lot more expensive than just creating the pamphlet. Your organization might not be able to afford the cost, period, or your boss may not agree to spend all that money just to make a minority of engineers happy in a few narrow cases. Then there's the question of how many people would actually consult the book of rationales; maybe it'd only be a handful.
I'm guessing most organizations tend to pursue a "minimum viable policy" tradeoff: spend as little effort as possible to create a policy that addresses a particular set of high-priority problems (since that is easily justifiable), and ignore more theoretical concerns like worker education and the personality preferences of certain kinds of individuals.
> On the other hand, a reason can convince people,
Policies very often have official reasons for just this propaganda purpose, but it's worth noting that the reasons cited for the purpose of motivating compliance are often chosen for the specific purpose of how well they are anticipated to motivate compliance and not how well they reflect the actual reasons the policy is adopted, and thus they often are not in practice a good tool for understanding how to challenge the policy effectively.
I think it depends on the person. For myself (and probably many people with the hacker mindset), I don't like useless rules and want a justification or I tend to think I "know better" which is of course sometimes true and sometimes not.
I used to think this was a rebellious streak but perhaps it's just from that desire to know how things work. Absent a reason, I'll find my own.
A lot of people don't care either way, rules make life simple so there's no need to complicate it further.
