The Best Practice Fallacy

I consider “Best Practice” in software development to be a fallacy.

Why?

Yesterday’s best practice is replaced by something new today.
And today’s best practice will be replace by something else tomorrow.

I don’t have a problem with setting good guidelines and habits, but let’s not call it “best” – that implies one right way (and there are enough knuckleheads in our industry who latch onto ideas with zeal that I really don’t want to encourage further).

Instead, let’s think of it as:

A “good” approach for what we are trying to achieve today.

Any way you cut it, any practice is just someone’s opinion of how things should be done, and it’s not necessarily based on varied experience or hard lessons.

In my own business I sometimes dictate how things should be done. A decision needs to be made, a pattern set in place and direction set. But I’m flexible and often review, improve and adjust.
(I also pay the bills so in absence of a better option what I say goes.)
But in no way are the decisions I make “best practice” or based on what others consider to be best.

I regularly make decisions contrary to current belief but are still valid and appropriate for the situation. I do analysis, consider options and put a lot of thought into decisions (other time there’s not much thought but a desire to learn through experimentation).

The reality is, in software there are very few things you need to adhere to. Create code and systems others can understand and maintain. Expect change. Don’t be an asshole.

Apart from that our industry is so young, so fast moving, and has so many possibilities and facets it’s impossible to define “best”.

So let’s just drop the bullshit, call a spade a spade, and admit we’re all learning and making this up as we go.