Software development seems to be all about best practices today. For every task that needs to be done, there seems to be the one single way to do it. Depending on who you ask that is of course.

I sometimes wonder if all those best practices are actually all that benefitial. It might be that there is a point where they actually hurt us.

Why are we so obsessed with following conventions?

Conventions are one of the most important things in software development. If people wouldn’t follow conventions, we wouldn’t be able to work in teams, we wouldn’t be able to build things that scale. We have to know what to expect in order to free us from the burden of having to understand each and every aspect of a process. We’d still be stuck in the 80ies. Or even earlier.

Why do developers love bikeshedding so much?

That being said, there is a point where a convention turns into a religious belief. If you don’t follow the convention you will go to hell, it’s inevitable. Conventions stop being there for your own good, but for their very own good.

This is where things go awry in my own experience. When you start discussing about how much whitespace to use after a hash character in Markdown (instead of discussing radical changes the same pull request contains, syntax errors too), you might be missing one very important thing.

Does the best practice benefit your product?

Why do we write software in the first place? To build great products. Great products are defined by great features. So, the next time you follow the best practice route, stop for a second and ask yourself “Does this help me buid a great feature?”. Many of the best practices defined help us to do so. Maintainabilty is a great feature, clean code too. Whitespace after hashes in Markdown isn’t. A mandatory review by multiple persons for a pull request that removes a stray console.log statement does not help your product. It hurts your product as it’s consuming valuable time for adhering to some bible like postulating. It eats someone’s valuable focus. Don’t do things for the sake of doing things.

Admit that you cannot assess some things

Many teams use code review extensively. Code review is great. In case you can get valuable feedback doing so. If in a certain situation you cannot get valuable feedback (because this is some side project written in LOLCODE or whatever) you will do nothing but encourage bikeshedding. Feedback for the sake of feedback.

“Hey, I think LOL08 said something about two blank lines after the CANIHAZ statements!”

You as a single person cannot assess and categorize everything. It is okay. Really. Sometimes you will have to trust other people in what they are doing and coming up with. Assume they are acting in good faith. It will work in 99% of the time.

Are we respecting the fact that people are different?

You might have noticed the following thing: people are crazy different. So why not let them solve problems in different ways? If something might be the best solution for you (whitespace after the hash!!!) it might totally confuse someone else. Even when writing software for machines, we are not machines. We are individuals. There is good and bad, but there rarely is the one single way to do it.

Ship great features

If you want to ship great features, make sure people are doing their best to deliver a good product in a good way. Enforcing a single, correct way of doing things at any cost will kill creativity and productivity. Be tolerant and try to evaluate things based on if they are actually good. Otherwise you might end up doing everything “best practice” but never ship a great feature. We don’t write software for the sake of writing software.