If you never met this question you are living somewhere else but not in the IT industry! Here I collected some practical examples you may refer to when facing the question in the title. Here at the start my position about rules and principles: freedom is made by great rules and this is a basement to maximise ability to change! This article is the continuation of Rules and exceptions article.

Defining the rules and observing them are two different questions. In good cases the rule creation and maintenance process utilises feedback from the productive life, what the rules are defined for to help. Did you catch the tricky part of this statement? The message in the back? Rules are changing! You have to be ready to reconsider your rules regularly by your own and by collected feedbacks.

If the title question raised too much, this maintenance procedure may be the first thing to investigate!

The most important route cause of our main dilemma here, that there are too many unusable rules or we would say bad rules out there. 

The definition of bad rules: if the consequence of breaking or using the rule has no effect to the main product, procedure of the company, then the given rule is a bad rule. Either if the rule is written or an unwritten one.

Example 1: Linate airport disaster

The Linate airport disaster shows the typical example of bad, unwritten rules. If you did not know this case, you can read all the details here. In very short, the situation was the following: there were so many critical problems with the ground control, like non-working ground radars or abusing ground signs. Each and every regular control audit recognised them, defects were reported properly but nothing happens...

Here we see some bad examples:

1. the unwritten rule, that deviation reports should only be archived is bad, since it has no effect to the productive operation
2. the bad approach of rule maintenance is also there; if you see too many deviances, by other word exceptions, you have to ask if the deviated rule is really needed or not? If the answer is yes (I hope it is for a ground radar...) then the responsible people have to bend every effort to solve the issue instead of simply record the deviations!

Example 2: SSL is a must 

I saw an example at a company, when each and every server to server communication had to use secure protocols. Since the secure communication was one of the most important target there, this principle is fine. The problem was, that the certificate management processes and the budget for proper certificates to buy were completely missing. The result was, that employees started to break this rule completely. The better case was if they did not use secure protocols at all, because it was simple to recognise; the even worse case was that they started to generate self-signed certificates on the servers and as it used to happen, forgot to renew them. Both the self-signed and the expired certificates cause issues on client side, therefore clients suppressed SSL related errors and warnings by default therefore everything seems to be fine in the daily operations. Certainly the regular audits recognised the problem of missing processes, some of the instances of self-signed and/or expired certificates but beyond the issue tracking records, nothing else was happened. There were hundreds of issue log records finally...

Let's play the game if someone asks: do we really need secure protocols? Assuming the answer is still yes, because of the security first approach. The next question would be: As we do not have enough money to use trusted certificates would self-signed be enough?

This second question is a bit more complex to have yes or no answer, but I can imagine the following answer: internal certificates are enough for those interfaces when the clients are internal, but expired certificates are still prohibited. We need a formal internal issuer solution with the central record of certificates with automated renewal process on the top. Internal clients must handle the company as trusted provider.

This change keeps the value of secure protocols, minimises the costs, kills bad practices and lets cleaning up error suppressions in clients. On the other hand you have to have appropriate rule maintenance process, which is open to recognise feedbacks. This approach recognises that "ideal" case is not reachable, therefore defines a real and valuable target, having better security level then the bad practice before, with a stable and audible constant quality.

It cannot be highlighted enough: good rules free you up, while no rules or bad rules make the chaos. Since our rules and principles are still not eternal verities, they need some care! This is one of the most important role of accountable architects!