Who removes rules?

Rules are an endless source of fascination and dread to me. How rules are created and why, how rules accumulate, how a set of rules shapes a system – it’s very, very interesting. Let me give you an example.

A couple years ago my wife and I were chatting with our tax advisor and he went off on a little rant about how the tax rulebook in Germany is getting thicker and thicker every year. “When I started out,” he said, “it was half the size! But they don’t know that!” The anonymous They he referred to are the young people working in the tax office today. His point: the young people who are just starting out working in the world of taxes don’t know that the whole world doesn’t come crashing down when you only have half the rules. Even though evidence points to the contrary.

My parents work in the construction business and my family on my mother’s side has done so for at least 70 years. Same thing: my mom says that every year they get an additional set of rules. Rules around what you can and can’t build, how to build it, how to document and who to report to what you built. She frequently points at (to me) normal-looking houses and says “you wouldn’t be allowed to build that today.”

I’m not here to say that everything was better before I was born. No, this is about rules. Two examples from two different worlds, the same pattern: rules accumulate over time. I asked my mom and my tax advisor the same thing: are rules ever removed? No, they both said, basically never.

If you’re like me and you have a voice in your head constantly asking “so how does this apply to software?” – relax, we’re here. In software we too have rules. We don’t have that many laws but we do have rules: checks in our CI systems, linters, and so on. But also rules that create processes in our companies that then govern how we create software.

Inside and outside of software, there’s one pattern that leads to a lot of rules: something bad happens, it’s agreed that it was bad and that we should avoid it from happening again, a rule is put in place to avoid it from happening again.

That’s when the first beads of perspiration begin to form on my forehead. You just made the rule book thicker!

Don’t get me wrong: I agree, the bad thing was bad, yes, we should avoid it from happening again. No one wants the f-word to show up in customer-facing documentation ever again. But look: rules aren’t free.

Rules need enforcement and enforcement takes time and resources. Every rule added to the tax code needs someone to know about it and to enforce it. Every CI check needs to run. Every linter needs your CPU when you save a file.

“Thorsten, you worried about a linter rule that takes 3ms to run?” First of all: I wish it was just 3ms. But even if, second: I’m not worried about a single rule, I’m worried about the rulebook growing thicker. A heavy book of linter checks will take longer than 3ms to run, I assure you. And every rule and process is a step in the direction of the rulebook getting thicker.

Because rules are sticky. They rarely have an expiration date. When they’re created it’s rare for someone to ask “do we really think the bad thing will happen again? Do we need this rule?” And once a rule or a process is put into place, you have to argue twice as hard for its removal than it was to introduce it. A rule prevents a bad thing, how can you argue to remove the rule that prevents the bad thing from happening? You want bad things to happen? You want the f-word to show up in the docs again? Thought so.

That’s how it goes, usually. And it worries me. It worries me tremendously. On a societal level because at least in Germany the chances are slim for someone to stand up and say: hey, look, maybe the bad thing will happen once in a thousand times and that’s fine and we’ll deal with that then and maybe the rule is an overreaction? And I’m not even talking about healthcare or traffic laws, I’m talking about the fact that I can only dump lawn clippings at the recycling place certain times a week because, oh my god, if we allow folks to just come and go and dump dead leaves whenever they please, someone might just show up and throw an old washing machine in there? Can’t let that happen.

On a software level because it took me two years of arguing for us to remove a linter check that makes sure no one uses single-letter variables and uses index instead of i in for loops.

On a company level because saying “do we really need that process?” always sounds like you’re against the thing the process is trying to achieve.

Most of all because a thick and getting-thicker rulebook narrows your possibilities and with that narrows your perspective on what’s possible. It takes an enormous amount of mental effort to see possibilities past a set of rules that are designed to prevent one-off edge cases.

It’s far easier to think “that’s not possible” than “yes, that’s possible, if we ignore these five rules here that then wouldn’t apply anymore anyway.”

Editorial note: I’m on vacation next week. I might skip the newsletter.