Reverse bike shedding

It is surely a lot of fun to spend time in the tabs-vs-spaces conversations. Or the naming schemes or other aspects of coding that do not really matter at all. But it hurts productivity. And we learned to stop such bike-shedding arguments and move on.

We have a new problem now.

One day a person announces "from now on all git branches should start with the department prefix". Because it could be useful information and could come handy in some situations. Or not. What's the harm having it there, right? And if someone asks "why?" or, even worse, proposes to put something else in the branch name instead she is quickly hushed with the messages like "git branch names do not matter, let's stop this bike shedding right here, ok?"

And now we have a policy in place which has no reason to exist. But we can not discuss it.

What if the person wanted to point out that "release/" branch prefix has a reason to exist because those branches are protected and even trigger different set of builds on their PRs, and that new policy of departments names does not make those branches different from each other in any meaningful way? That's bike shedding.

What if the person wanted to point out that there are other fields in JIRA which actually do affect the workflow and perhaps that should be in the name instead? That's bike shedding.

What if... It does not matter. The decision is made. It has no rationale to support it, but it does not matter. You can not change it.

Because a change would require a reasoning to support it. And reasoning about something utterly unimportant is bike shedding.

You better make the right call the first time you make a decision. And God forbid your company's development process would ever change.

Posted On


Tags: / /