But bro, these are the good practices.

disclaimer: This post is opinion based.

“Because these are good practices”. More and more I have heard this answer being thrown around as an “end of conversation” tactic and I believe it is time for us to challenge the idea that everything in Software Development can be boiled down to step by step rules that can be followed at all times.

In my 4 years of industry, I have heard different “universal truths” that go hand in hand with Newton’s gravitational law. Here are some examples that I can think of.

1. If your function has more than X lines, you are doing something wrong.
2. Good code does not need comments, your code needs to be easy to read and the documentation itself, when comments are necessary, you are doing something wrong.
3. Every single line of code needs to be tested, if you do not test all your code from the beginning, you are wrong.
4. Always use forEach instead of for loops. (What???).

Perhaps I am too skeptical, or perhaps those who make such claims are so far ahead of me, that they were able to analyze in their heads every different scenario, of every different codebase, at all times and were therefore able to make such strong claims.

There are 3 main issues with such an approach to software development.

No, they are not laws of nature, and they are not applicable at all times

This should go without saying. Multiple times I have found myself in Technical arguments where two different ways of doing the same thing was being discussed. While one side’s main argument for doing X was based on solid data, pros and cons, examples and careful analysis, the counterpart was defending the Y way of doing things because it was considered a “Good Practice”, or because Y simply had a “smell to it”, which they could not really explain what it was. These practices have their own place and time, even those who created them did not believe they were a one size fits all solution.

That being said, I would like to add an even better practice.

“As a best practice always rethink your decision when your main point to back it up is that fact that it is considered a good practice”.

Such an attitude stands in the way of new and better approaches to problems from emerging.
Following industry good practices on itself is not a problem and SHOULD be encouraged, the problem is when some engineers no longer know why they do what they do and find themselves repeating sentences they read in a book or heard from a colleague.

Multiple times I have seen developers go against their own common sense and experience to follow someone’s good practice, when they had a much better claim to follow their own.
But what happens when we all start following these ideas and collectively use them to suppress unorthodox solutions.

Stagnation happens. Even worse, what happens when the good practice in question is not so good after all?

On a personal experience, back at a Startup I used to work at, people got into the behavior of creating environment variables everywhere, spamming them without really thinking of it and claiming that it was good for readability and to keep consistency. It reached a point where CONSTANT VALUES were being used as environment variables, even thought they would always be the same.When challenged against it, the answer would be: It is a practice that we follow, and to not do it is a code smell.

“If you claim that 8 squared is anything but 64, you are wrong. If your function has more than X lines of code, well, I don’t know, maybe?”

When writing software becomes a step by step recipe, boringness can creep in.

I have always believed, and looked at Coding as a way of expressing creativity and imagination. There are numerous ways the same piece of code can be written, some are good, some are bad, some good enough, and there is beauty to it. We need to start looking at experimenting with code as part of a natural process that will allow the industry to reach better standards.

Every time a discussion is “won” by the good practice tactic I see someone’s creative side being suppressed and the message that innovation is not welcomed can come across, even if not intentionally.

Of course there are nuances to it. Trying new solutions at a 15 engineers startup is a whole different beast from doing the same at a FAANG, while the first can afford more trial and error, the ladder can emphasize code base consistency.
Depending on the context, there should be a sweet spot between innovation and consistency and it should be part of our job to find it.

Then when are the best practices welcomed?

As with so many things in life, when to follow or not follow a best practice is not black and requires common sense. In general they should be used as a fallback when it is not clear what the best solution for a given problem is.

They become especially important at medium to large companies where hundreds of developers are working on the same codebase and consistency helps to boost velocity.

That being said, they should NOT be repeated without a clear explanation but instead based on pros and cons as to why they should be followed.

All in all, its mostly common sense.

If this article was useful to you, please follow me on my social media :)

twitter: @onurbraga
instagram: @brnbraga