Best Practices Will Be Better Tomorrow

Best practice evolution from dogma to wisdom

If you hang up with engineers for long enough a phrase "best practice" will come up sooner or later in some context. Of course, this is not something unique to software development. Other fields also have them. However, I think what makes it particularly unique in software development is that these practices are rarely standardized. What one developer usually refers to "best practice" is often a piece of common knowledge that is accepted by the industry or the community through continuous practice. It is passed from one developer to another through documentation, comments in pull requests, answers on StackOverflow and informal word of mouth.

We, developers, are still like medieval artisans forging and melting the code while teaching junior developers our approach. These junior developers eventually move to another blacksmith using similar tools but with slightly different best practices. Some feel astonished, thinking, "Wow, I thought my previous master was skilled, but this master is even more skilled. I can learn so much from him!". Others question the abilities of a new master and prefer to learn on their own. Over time, all of them become masters themselves with their own vision of best practices. The never-ending cycle of better best practices.

So, what's the problem then? You might say "Come on, man, don't be such a killjoy! Let people use best practices however they want". I have no problem people using best practices, but I do think it is a problem when best practice becomes a goal.

Imagine a case, when someone suggests using k8s and Mesos in a small company with less than 10 engineers. Why? Because it is cool and scalable, but mostly because it is cool. After all, that's what "true engineers" in Big Tech companies do. And for them, k8s might indeed be a best practice. Clearly, engineers who think it's a good idea to integrate k8s into a small company that doesn't plan to expand the engineering team don't think about the relevance of k8s – they just want to use it. And put it in their CV afterward.

Another example where people love to emphasize best practices is design patterns or design principles.

There are actually good examples. Let me give you one of them.

At the beginning of my career, I worked with Ruby on Rails for several years. Ruby on Rails is a traditional web framework that popularized MVC (Model-View-Controller) pattern and inspired frameworks for other programming languages. Rails community has LOTS OF best practices, to the extent that they become dogmatic. There are conventions about putting certain files in specific folders, arranging logic inside of particular modules, specific approaches to certain tasks and so on.

And these conventions and practices have always evolved over time.

For instance, in the early days of Rails there was a concept of fat models, skinny controllers (I think it's still popular) which suggested that one should place all business logic inside models, with controllers having it as little as possible. Later *fat models* also became a problem, and new approaches emerged like service objects and value objects leaving the model responsible just for defining a scheme and a data layer talking to database.

Retrospectively, I understand that these conventions of the framework and its best practices were the reason for success of Rails. They attracted, and continue to attract, beginner developers, which is good for them, because they have strict rules how to obey in different contexts, that are not familiar yet.

As I gained more experience I slowly went away from Rails, but the Rails community approach holds a special place in my heart.

Then the same played out in frontend web development. JavaScript community is especially notorious for reinventing best practices at lightning speed often causing mockery from other communities. But that's just how it is – JavaScript community is young and working in a very dynamic ecosystem built on a language that was never designed to handle the complex tasks it’s now expected to handle. When React first came out, there was no clear state management solution at all. Everybody invented their own flux architecture, only to eventually arrive at hooks six years later. Fast-forward to today and most frontend frameworks come with reactive state management built-in.

I'm pretty sure you would see the same picture in other communities.

A best practice is always a product of specific community, reflecting its current level of development in a specific point of time. Technologies grew together with its community and level of their core contributors. The more experience they have, the more mature best practices are.

And some of them are carved in stone, remaining unchanged, like the practice of not storing passwords in plain text in a database.

Don't make best practice a dogma or a goal – remember, tomorrow something better might come along.