Yet, there is a one challenging thing in following the rules. If you agreed to follow them, you should not allow for any exception. Why? Because the first exception is the first step for more exceptions. The more exceptions are made, the less valuable the rule becomes.
Why not?I assume all rules have already been discussed within the teams. There was a group of developers (maybe you were there as well) that met together, brought their ideas and arguments and talked. They were challenging theirs ideas and assumptions. And even if there were any doubts about a particular rule I believe the most of them were expressed and discussed there and you agreed after all that it is better to follow the rule rather than not.
It was a conscious decision, not lucky guess.
Now you are in the place where you think that maybe it would be better to break the rule. To make an exception. Only once. Only this time.
Well, do you really believe that it will be “only this time”? Because I’m sure it won’t be.
The first exception makes a significant difference. Why? Because there has already been someone who convinced other developers that flouting the rule in some cases is ok. If so, maybe my case is similar? And even if it is different, maybe it is “just another case” that should allow for breaking the rule? Or maybe the rule itself is not so good at all? Maybe it is not a rule, but should be treated as a hint?
So many doubts. Why? Because it is no longer clear. There was the exception already, so what difference will another one make?
It is hard to follow the rules. Rules are borders that cannot be crossed. However, sometimes it is so tempting, it is just easier, but… yeah, there is a rule.
Yet, if an exception was made, the rule is no longer such a strong blocker. It became a warning sign, not a stop sign.
This is exactly like quitting smoking. Your resolution is to not smoke cigarettes at all. But if you fail once, whenever you will have an avidity to smoke one more time you will hear a voice in the back of your head that will continuously repeat: ‘you already did it and it was not a big deal at all’, ‘does another one really make a difference?’, ‘you already broke a rule, so next time won’t change anything’. Don’t be the one who breaks rules!
What if you are right?In the first paragraph I didn’t talk about one important thing - you may be right. There’s a chance that you found a good reason which makes the rule not so perfect, because following it in some cases makes more harm than good.
What should you do in such case? Well, I will repeat myself - don’t be the one who breaks rules!
But it doesn’t mean that you should follow this particular rule only for the sake of not breaking the rules. There is one more possibility, instead of breaking the rule you may change it!
If you found something new that was not taken into consideration when you were agreeing with the rules, or you found new arguments for the doubts you had the best idea would be to challenge the rule once again.
It can end in two ways. Either you will convince others and the rule will be changed or you will get feedback which will allow you to understand why following the rule, even in your case, makes sense.
Regardless of the result someone will learn something new, someone will grow and this is always valuable for the particular person. And the project as well.
And the rule won’t be broken.
If you convince others to your rights, you will still write the code that you wanted to write, but this time it will happen without this huge negative impact - there will be no exception, you will just follow the rules.
Be the one who makes a changeNo one said that rules cannot be changed. Everything changes and if there is nothing new, no new challenge it would mean only one thing - the project does not grow any more.
That’s why you should challenge existing ideas and rules, but don’t make any exceptions.
Exceptions lead to more exceptions and that results in rules that are no longer followed.
Even if they’re still declared somewhere and you still pretend they help to protect something.