We need less “it’s good because it’s standard” and more “it’s standard because it’s good”.
Let a so-called best practice stand (or fall) on its own merits (or lack thereof), and question and test merits where and when needed. Appeals to Authority, Tradition, or Popularity are all logical fallacies.
I generally find the IETF approach to this to be pretty good. They generally want working implementations before standardizing an RFC and it’s pretty rare to find a genuinely flawed RFC after it’s gone through the draft/review process. Some of old ones are showing their age quite a bit, but in context they’re quite good.
I know it’s a rant, but god do I feel this in my soul.
I’ve seen good and simple procedural code made of easy to understand functions, conditionals and loops in a single file get turned into an object oriented monster full of virtual function call and endless indirection spread across multiple files, making the actual logic impossible to understand. And the guys who does that tell you that it make the code “cleaner” and better. After all, it follow Demeter, the SRP, the testing pyramid and other “good practices”.
Well…. as the guys who has to debug that kind of code when there are production issues, no, it almost always does not help, it’s more often than not harmful. By experience, it’s easier to solve problem with plain and simple code, because I can see what is going on what function are actually called, and what data is mutated, and when. Because the complexity that is so proudly “hidden” is exactly the complexity that I want to see upfront, because I need to see it to be able to solve the problem!
You know what make code easy to debug by debugging a lot of code. You know what make readable code by reading a lot of it. You know what make maintainable code by maintaining lot of it. Good practice can guide but will never substitute for experience, and this is why they must never, ever be turned into law or religion.
“Best practices” are pretty useful when you want the “standard solution” to a particular problem. And you often do; a typical small software company probably shouldn’t completely rethink how to design an ergonomic workplace, accounting standards, or how to arrange pensions.
“Best practices” are a good starting point, but shouldn’t be a thought-terminating cliche, in your area of expertise.
they’re mostly pounded by either 1) various types of zealots, idiots, and assholes who abuse these kind of “best practices” as an argument from authority, or 2) inexperienced programmers who lack the ability to judge the applicability,
Everyone else just says “X is better because Y”. This is an actual argument that can be engaged with, and engaging with actual arguments is what discovers the best solution for the situation at hand.
Speaking of engaging with actual arguments, can we not see that the author is committing the exact sin that he is inveighing against? What “best practices”, specifically, are you taking issue with? Who are the “zealots”, “idiots”, and “assholes” here? Without specifics I cannot judge the merit or demerit of your argument. This is trash.
Chernyshevsky once wrote, “there is no abstract truth; truth is concrete”. Best Practices are abstracted from concrete practice, and if you’re going to argue that a given Best Practice is a false abstraction, you have to retrace the steps back to the concrete practice and show how it ignores important context.
Every law has its jurisdiction area. Rant shows that those laws are not universal — well, thank you very much, but they exist not for the blind computer-like interpretation, but rather to transfer easy-to-grasp concept from one non-ideal person to another.
Example of such application: Remember that most of the concepts have anti-concepts (e.g. jack of all trades + master of none — people usually don’t discuss right or wrong is the guy who is jack in their case, but rather try to understand what is better in your case, to have everything done poorly or something done well.)
[Comment removed by author]
I agree with this, but once again the answer to all code structure questions is, “it depends”.
It’s depressing how much the industry wants this not to be true and never seems the learn the lesson.
We need less “it’s good because it’s standard” and more “it’s standard because it’s good”.
Let a so-called best practice stand (or fall) on its own merits (or lack thereof), and question and test merits where and when needed. Appeals to Authority, Tradition, or Popularity are all logical fallacies.
I generally find the IETF approach to this to be pretty good. They generally want working implementations before standardizing an RFC and it’s pretty rare to find a genuinely flawed RFC after it’s gone through the draft/review process. Some of old ones are showing their age quite a bit, but in context they’re quite good.
I know it’s a rant, but god do I feel this in my soul.
I’ve seen good and simple procedural code made of easy to understand functions, conditionals and loops in a single file get turned into an object oriented monster full of virtual function call and endless indirection spread across multiple files, making the actual logic impossible to understand. And the guys who does that tell you that it make the code “cleaner” and better. After all, it follow Demeter, the SRP, the testing pyramid and other “good practices”.
Well…. as the guys who has to debug that kind of code when there are production issues, no, it almost always does not help, it’s more often than not harmful. By experience, it’s easier to solve problem with plain and simple code, because I can see what is going on what function are actually called, and what data is mutated, and when. Because the complexity that is so proudly “hidden” is exactly the complexity that I want to see upfront, because I need to see it to be able to solve the problem!
You know what make code easy to debug by debugging a lot of code. You know what make readable code by reading a lot of it. You know what make maintainable code by maintaining lot of it. Good practice can guide but will never substitute for experience, and this is why they must never, ever be turned into law or religion.
“Best practices” are pretty useful when you want the “standard solution” to a particular problem. And you often do; a typical small software company probably shouldn’t completely rethink how to design an ergonomic workplace, accounting standards, or how to arrange pensions.
“Best practices” are a good starting point, but shouldn’t be a thought-terminating cliche, in your area of expertise.
Speaking of engaging with actual arguments, can we not see that the author is committing the exact sin that he is inveighing against? What “best practices”, specifically, are you taking issue with? Who are the “zealots”, “idiots”, and “assholes” here? Without specifics I cannot judge the merit or demerit of your argument. This is trash.
Chernyshevsky once wrote, “there is no abstract truth; truth is concrete”. Best Practices are abstracted from concrete practice, and if you’re going to argue that a given Best Practice is a false abstraction, you have to retrace the steps back to the concrete practice and show how it ignores important context.
I’ve been saying this for over 10 yrs. I’m very happy to read others agree.
Every law has its jurisdiction area. Rant shows that those laws are not universal — well, thank you very much, but they exist not for the blind computer-like interpretation, but rather to transfer easy-to-grasp concept from one non-ideal person to another.
Example of such application: Remember that most of the concepts have anti-concepts (e.g. jack of all trades + master of none — people usually don’t discuss right or wrong is the guy who is jack in their case, but rather try to understand what is better in your case, to have everything done poorly or something done well.)