I think quite a bit about “Best Practices”. Partly it’s me reacting to the aversion I have for that phrase, best practices, and partly it’s me trying to figure out a better way to say what we mean when we say “Best practices”.
What are we trying to convey when we say “Best Practices” anyway?
At least part of the time (though I suspect more of the time than we care to admit) we use that phrase as a way to shut down dissension or as an ‘appeal to authority’. I don’t think it’s done maliciously; but there is an element of ourselves that gets tied to a course of action, and even if it may objectively be wrong for our context, the ego is the ego, and the appeal to authority, well… feels good. It almost feels righteous.
Another part of the time it’s as a protection in case something goes wrong. If we’re doing it, and other people do it, it can’t be wrong, right? We can’t be held responsible for doing what is considered a ‘best practice’.
And for some situations, a context free ‘best practice’, may actually be a best practice and we use the term because the stars happen to line up and it’s an actual best practice.
I think this is far less common in practice than we judge it to be.
Too much of what we do when we build software is context-sensitive, that is, the particular circumstances and facts surrounding the why and the what are as important (if not more so) than the “typical” means we employ to build software.
Or put another way, we have far fewer immutable laws when building software than when engineers are designing and building roads or bridges. Gravity or inertia will not suddenly change on the bridge engineers, but our circumstances — our context can change on a dime.
I don’t know how far this thought extends, but I like to think that when I’m designing software, the context I’m designing on is front and center. It is the most important part, because it’ll define the rules by which we operate. So instead of using best practices, I use context-sensitive practices. Maybe that’ll keep my hubris at bay?