Breaking the rules
Scenario 1 – You approach a 4 way stop sign, with exceptional visibility in all directions. You have to decide if you will roll through the stop sign, or be a ‘good driver’ and come to a full stop. Since you see no benefit in fully stopping you decide to roll on through. As you drive on a motorcycle officer pops out from behind a bush and writes you a ticket for not complying with the law.
Scenario 2 – You need to finish a new feature on a project, so evaluating the design options and impact of them. You can either follow the standard approach that your team uses or save half the time and implement it in a much simpler way. After realizing half the effort for the same effect is the best value for the customer you decide to use the simple implementation. As you finish up and commit your changes into source control, the commit notification alerts the resident ‘architect’ and they scold you for not following standards.
The point I am trying to convey is that rules/standards should only be in place to help people that need guidance, either from a lack of knowledge, or lack of a clear choice. Unfortunately the inflexible nature from the bodies of governance stem from a lack of trust. If you don’t have trust in your developers decisions making capabilities then you have a broken system, and your rules are more constraining then they are helpful.
To sum it up in one line, if you are familiar with the Serenity Prayer then this format might sound familiar…
Grant me the serenity to follow the rules, courage to defy the rules , and the wisdom to know when to do which.
Tell us what do you think.
Websites mentioned my entry.
There are no trackbacks on this entry