Against Best Practices
arp242.net
Against Best Practices
1–10 of 218 posts
Re: Against Best Practices
#2How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics.
For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty lines sometimes, but that's a good compromise.
May be there should be a good compromise when it comes to "best practices"? Like "DRY" is not always best, but it's always good enough, so extract common stuff every time, even if you feel it's not worth it.
I often deal with this dilemma when writing Java with default Idea inspections. They highlight duplicated code and now I need to either disable this inspection in some way or extract the chunk of code that I don't really think should be extracted, but I just can do it and move on...
Re: Against Best Practices
#3How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…
I think we're still in the "phlogiston" era of software development.
Re: Against Best Practices
#4How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…
Other engineering disciplines have certification, codes and regulations for specific domains, which are enforced by law.
DRY is a perfect example though of something which in moderation is a good idea but as the article says is vulnerable to ‘inexperienced programmers who lack the ability to judge the applicability’ and if over-eagerly applied leads to over-abstraction and premature abstraction which does more harm than good.
Re: Against Best Practices
#5It occurs to me that the author is explaining his best practice is to look at someone else's best practice with a gimlet eye and take what you want from it. So I wonder how to apply his best practice to his own best practice?
Re: Against Best Practices
#6Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.
Re: Against Best Practices
#7How other engineering industries deal with this phenomena? Why those approach do not work with programming? I feel silly sometimes because software development is huge industry and we don't have consensus on basics. For example I think that strict formatting is a good thing. Since I tried to use Prettier I'm using it and similar tools everywhere and I like it. I can't do vertical alignment anymore, it eats empty line…
Some reasons I would say:
- I think SW needs much more creativity than other industries.
- Typically SW is not mission critical (in mission critical things, it IS pretty much regulated to uncomfortable extremes)
You could regulate it to death, and would probably have some positive impact by some metric, but you would be easily overtaken by FOSS, where for sure there will be less restrictions.
Re: Against Best Practices
#8Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.
Basically if you know exactly why the best practice/rule is in place, and know for sure it does not apply, just skip it. But not before.
Re: Against Best Practices
#9Best practices and such shouldn't be obeyed as "laws" but guidelines for general work. Once in a while there's good reason to avoid / skip them for whatever reason.
The bigger issue is that developers (me included) are usually making the decisions in their own heads. Usually the reasons are quite ok but they are not really said out loud or documented.
I've been stumbled upon this as both developer trying to get their code approved and when doing a code review.
For the developer it feels super annoying that somebody nitpicks about things which the developer has probably gone through in their heads already and ended up with the resulting solution. Just like Martin in the post complains and reacts passive aggressively towards reviewers mentioning these things.
For the code reviewer it feels like the developer is being sloppy or doesn't care about our common way of doing things thus increasing the need to nitpick and explain so that the developer understands how it should be done.
The solution for this is actually quite easy: document in the comments and in the Pull Request _why_ you're breaking team's / company's guidelines and why you think it's warranted for solution for this case. This seems to remove quite a lot of friction.
Oh and of course it doesn't mean that the guidelines should be broken all the time just because one thinks this kind of stuff is for "idiots|assholes". When working as a team, we need to adhere to common way of working for most of the time.
Re: Against Best Practices
#10While I guess most would agree all the cited practices have been abused what is really the alternative? Absence of practices does not make things better - history has plenty lessons there. To run medium to large scale projects one needs patterns to ease communication and integration.
The real question is how do we prevent best practices to be perverted and I fear the answer is having the right people in the right places. The one best practice to rule them all: Have knowledgeable balanced people who know when to break the rules.