I don't think you can really make a blanket statement like this. When you make blanket statements, you're ultimately basing a decision on superstition, rather than need or evidence. It's why I don't really care for anything that claims to be "best practices". The term "best practices" really just means "this worked for us in our situation". That's great, and one should be aware of such things, but that doesn't make it a standard or a law.
The term "best practices" really just means "this worked for us in our situation"
I strongly disagree. Obviously there are always exceptional circumstances, but if something is really a best practice, that means "if you decide not to do it this way, you should have a good reason for that decision".
Now I would agree that people are too quick to call something a "best practice", when really it's just their personal preference (e.g. "always use semicolons in JS", or "never use semicolons in JS").
Well, that's really what I mean. Too many people call their personal habits "best practices", to the point that I just can't be bothered to listen to what the general population of programmers has to say about how I do my own job.
Exactly. If you are going to call something "best practice" then first you need to put it in a formal document, and second, that document should be signed off by a wide panel of experts from a broad cross-section of the relevant industry.
The coding style guide put out by your 12 member startup isn't "best practice" for everyone. It's just best practice for continuing to work there.
I disagree with your statement. I believe that "best practices" means that "this is probably how it should be in the majority of uses." Obviously each situation is different and not everyone's solution will work for you, but I'd be willing to be that more often than not, it would.
Whenever something deviates from best practices, I would think that that raises a red flag for justification of difference.
Yeah, but justify to whom? To the Jr. programmer trying to move up in the company, no matter who he has to throw under the bus to get there? To the entrenched Sr. programmer who uses effort to make up for a lack of skill? To the manager who doesn't know anything about programming?
I would argue that a quorum of engineers would generally agree with whatever is justifiably deviating from best practices. If it makes sense to you because of good engineering reasons, then it should probably make sense to other engineers. Reality perhaps dictates otherwise, but that's what it should strive for.
Comments
I don't think you can really make a blanket statement like this. When you make blanket statements, you're ultimately basing a decision on superstition, rather than need or evidence. It's why I don't really care for anything that claims to be "best practices". The term "best practices" really just means "this worked for us in our situation". That's great, and one should be aware of such things, but that doesn't make it a standard or a law.
I strongly disagree. Obviously there are always exceptional circumstances, but if something is really a best practice, that means "if you decide not to do it this way, you should have a good reason for that decision".
Now I would agree that people are too quick to call something a "best practice", when really it's just their personal preference (e.g. "always use semicolons in JS", or "never use semicolons in JS").
Well, that's really what I mean. Too many people call their personal habits "best practices", to the point that I just can't be bothered to listen to what the general population of programmers has to say about how I do my own job.
Exactly. If you are going to call something "best practice" then first you need to put it in a formal document, and second, that document should be signed off by a wide panel of experts from a broad cross-section of the relevant industry.
The coding style guide put out by your 12 member startup isn't "best practice" for everyone. It's just best practice for continuing to work there.
I disagree with your statement. I believe that "best practices" means that "this is probably how it should be in the majority of uses." Obviously each situation is different and not everyone's solution will work for you, but I'd be willing to be that more often than not, it would.
Whenever something deviates from best practices, I would think that that raises a red flag for justification of difference.
Yeah, but justify to whom? To the Jr. programmer trying to move up in the company, no matter who he has to throw under the bus to get there? To the entrenched Sr. programmer who uses effort to make up for a lack of skill? To the manager who doesn't know anything about programming?
You're mixing politics with good engineering.
I would argue that a quorum of engineers would generally agree with whatever is justifiably deviating from best practices. If it makes sense to you because of good engineering reasons, then it should probably make sense to other engineers. Reality perhaps dictates otherwise, but that's what it should strive for.