Years ago, I read a blog post, now lost somewhere out there on the internet, that spoke on the concept of focusing on actions with outsized beneficial effects. For example, doing a short amount of exercise pays back with enormous longevity and health benefits.
That post came to mind again because I’ve recently noticed an opposite kind of imbalance, one where a small action creates a big annoying hindrance, one I often see in system architecture and code reviews:
The entire concept of the “best practice” should be considered anathema in the engineering field. When you distill best practices down to their simplest form, they are, ultimately, a form of engineering via checklist. By this term checklist engineering I mean any form of engineering where we have surrendered some amount of decision making and critical thinking to other people who have formed a “best practice list”.
This is opposed to reasoning for ourselves at every possible decision making point for why we make any particular choice.
Sure, I recognize that checklist engineering is probably useful for getting an implementation to a form that is “decent and not the absolute worst possible”. Best practices get you to a middle-of-the-road solution, but rarely to what the truly “best” solution would be for your particular situation. I think it’s an ultimately harmful way to go about doing engineering. When you work with increasingly complex systems, and need to work within bespoke contexts unique to a business’s situation where other needs are critically at play (e.g. time, complexity, availability, budget, etc.), you will encounter an increasing number of situations where the best practice simply is not the best.
Their name alone implies they are the ‘best’ way to do anything, but this is far from the case. There would be a lot less of a problem if we all agreed to call them “recommended practices that generally work most but not all of the time”. But by calling them ‘best’, we get engineers taking this at face value and following them with strict observation, not straying from them at all, and sometimes unable to answer why they are preferred. I argue this: abandon the concept of ‘best practices’ as absolute solutions and instead recognize them only as potential ones.
Rigidity to best practices also just incentivizes poor engineering decisions. There are a number of times I have encountered implementation problems where I could either 1. try to implement a solution I discovered that would confer a non-obvious benefit, but doing so, I predict, would lead to someone calling me out for not following a so-called best practice, or 2. I simply abandon the idea and go with the so-called best practice in order to get my work delivered. I find that if you do stand your ground, and argue your case, others will also come to realize the benefits of your solution over the ‘best’ practice. But of course this cannot always be, sometimes time constraints often make this litigation impossible.
Unless a change is evidently suboptimal or harmful, it’s completely fine to have some implicit trust in the author’s decision to select an implementation that is not a best practice. Your colleague, presumably a fellow engineer, has used their brain to go with one method over another. If there is no difference in the ultimate effect it has over the effect of the best practice, why make them justify their decision? Why waste time forcing others to redo their work for no difference in result? You must focus on potential effects. To be ignorant of the possible reasons why an author decided to opt for one method over another is to reduce them to someone unable to reason or do anything on their own. I’m not saying to be lazy, cut corners, or accept any solution which does. In fact, just the opposite.
Instead of saying “not best practice”, the reviewer should always provide justification for why their recommendation is objectively better. They need to explain why it is worth the time to implement in the context of the business needs, and critically, demonstrate what the actual effective difference would be. In doing so, the reviewer will either: 1. teach the author why the recommendation would be superior, or 2. discover, by trying to justify their recommendation, that there actually is no difference at all. By having the reviewer justify the best practice, this also achieves better balance in the review process and may incentivize, as I explained earlier, better engineering practices overall. It does not leave the author, pressured to finish on a deadline, in a disadvantaged position to either defend or resign their idea altogether in order to get the merge done.
A computer science quote comes to mind: “premature optimization is the root of all evil”. Recognize that the very practices people cultishly abide by may themselves be suboptimal or the cause of unnecessary maintenance! This is especially true any time they broadly recommend abstraction. Let’s assume there is a best practice X that is technically more extensible than Y. Now ask yourself: Does the context of the application have (or will ever be expected to have) enough complexity that implementing X would lead to a net-reduction in complexity? Or is the project small enough that X may actually introduce more complexity? Would implementing method X force the author to undo a lot of work and introduce major business delays? Will these delays ever lead to a return on value?
This is why I am typically happy to approve work as long as it demonstrates: 1. it affects a change that works, 2. it isn’t suboptimal or harmful, and 3. it doesn’t add unnecessary future maintenance. If it meets all of these criteria, who cares if it doesn’t follow the best practice? To reject someone’s work for some other arbitrary practice that confers no other benefit is to give net-negative value in a personal quest to be some kind of inquisitor, making them answer for their implementation which slightly deviated from some list.
As an engineer, abandon best practices and all forms of contextless broad recommendations as anathema. Instead, harness your capacity to understand effects, and give your full attention to each engineering issue you encounter on a case-by-case basis to make your own determinations.