Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against Best Practices

arp242.net

Post reply on HN
Print view View original

101–110 of 218 posts

Re: Against Best Practices

#101

Post by danenania »

gspencley wrote: post #66

> but because 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, The author might go on to make other points that are worth discussing, but lays out his supporting arguments clearly in the opening paragraph. Best practices do not neces…

> Best practices do not necessarily do harm because they offer bad advice, they do harm because they are advocated for by zealots and the inexperienced.

I think the point is that blindly suggesting "best practices" often is bad advice.

It's a common form of bikeshedding—it allows someone to give their casual two cents without doing the hard work of thinking through the tradeoffs.

Re: Against Best Practices

#102

Post by whstl »

taeric wrote: post #35
vbezhenar wrote: post #2

How 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…

What makes you so sure they do? Go to the hardware store and behold how many fasteners there are. Go down the rabbet hole of pipe fittings. Consider the optimal size of lumber, someday. And then get ready for the horrors of electrical connections. Not necessarily in how many there are; the real horror is how many think there is a "one true answer" there. You can find some solace in learning of focusing effects. But,…

That's a great point.

In the end, other engineering areas also have lots of "it depends" situations, where often there are multiple correct answers, depending on availability, legislation, safety, physical constraints, etc.

Perhaps in software engineering people are just too quick or immature to judge.

> rabbet hole

Nice pun ;)

Re: Against Best Practices

#103

Post by KronisLV »

TehShrike wrote: post #74
agentultra wrote: post #55

I think the rejection is too strong in this article. The idea of, “best practices,” comes from an established Body of Knowledge . There is one published for software development called the SoftWare Engineering Body of Knowledge or SWEBOK; published by the IEEE. The author seems to be arguing for nuance: that these “laws,” require context and shouldn’t be applied blindly. I agree. However they shouldn’t be rejected ou…

I think it is best to strongly reject the idea "best practices will always benefit you". Most best practices that I have been told about were low local maxima at best, and very harmful at worst. If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it. It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason…

> Most best practices that I have been told about were low local maxima at best, and very harmful at worst.

This matches my experience, though sometimes they indeed will be helpful, at least after some consideration.

> If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it.

In certain environments this will get you labeled someone who doesn't want to create quality software, because obviously best practices will lead to good code and not wanting to follow those practices or questioning them means that you don't have enough experience or something. Ergo, you should just apply SOLID and DRY everywhere, even if it becomes more or less a cargo cult. Not that I agree with the idea, but that way of thinking is prevalent.

(not that I agree with that, people just have that mindset sometimes)

Re: Against Best Practices

#104

Post by f1shy »

throw310822 wrote: post #34
f1shy wrote: post #8

Earlier quoted context omitted.

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. https://en.wiktionary.org/wiki/Chesterton%27s_fence

I would reverse this: if you can explain to me exactly why your so called "best practice" applies here and now, good. Otherwise it's a nice input to have in the discussion, but nothing more.

I could agree. It boils down to “you have to use your brain, and not try to invent and follow blind some rules”

Re: Against Best Practices

#105

Post by layer8 »

The advantage of best practices is that you have something you can follow without having to analyze the situation in depth. The disadvantage of best practices is that you may have to analyze the situation in depth to notice that they maybe aren’t the best choice in the specific situation. The harm that best practices can do are lessened by viewing them as a rule of thumb conditioned on certain premises rather than as a dogma.

Re: Against Best Practices

#106

Post by alach11 »

lkrubner wrote: post #80

Dan Morena, CTO at Upright.com, made the point that every startup was unique and therefore every startup had to find out what was best for it, while ignoring whatever was considered "best practice." I wrote what he told me here: https://respectfulleadership.substack.com/p/dan-morena-is-a-... My summary of his idea: No army has ever conquered a country. An army conquers this muddy ditch over here, that open wheat fiel…

Wow what a fantastic little article. Thanks for writing and sharing that.

Re: Against Best Practices

#107

Post by layer8 »

agentultra wrote: post #55

I think the rejection is too strong in this article. The idea of, “best practices,” comes from an established Body of Knowledge . There is one published for software development called the SoftWare Engineering Body of Knowledge or SWEBOK; published by the IEEE. The author seems to be arguing for nuance: that these “laws,” require context and shouldn’t be applied blindly. I agree. However they shouldn’t be rejected ou…

While I like the idea of SWEBOK, the actual SWEBOK book is not very useful though, quite incomplete, biased, and not up to date.

There was recently a HN thread about it: https://news.ycombinator.com/item?id=41907412

Re: Against Best Practices

#108

Post by BeFlatXIII »

burnt-resistor wrote: post #69
chthonicdaemon wrote: post #51

Rules travel further than reasons. The problem is that a lot of true things in the world are counter-intuitive. So insisting that all the rules "make sense" in an immediate way is clearly a non-starter. In the safety industry there are many examples of best practices that are bred from experience but end up being counter-intuitive to some. For instance, it might not make intuitive sense that a pilot who has gone thro…

It will never happen outside of limited industries because it would appear to be a loss of "freedom". I think the current situation creates an illusory anarchist freedom of informality that leads to sometimes proprietary lock-in, vulnerabilities, bugs, incompatibility churn, poorly-prioritized feature development, and tyranny of chaos and tech debt. There are too many languages, too many tools, too many (conflicting)…

I disagree slightly here. There may be one (1) dominant formal language that's used as the glue code that gets run on machines and verified, but it will have numerous font-end languages that compile into it, for ease of typing and abstraction/domain fit.

Re: Against Best Practices

#109

Post by gbacon »

lkrubner wrote: post #80

Dan Morena, CTO at Upright.com, made the point that every startup was unique and therefore every startup had to find out what was best for it, while ignoring whatever was considered "best practice." I wrote what he told me here: https://respectfulleadership.substack.com/p/dan-morena-is-a-... My summary of his idea: No army has ever conquered a country. An army conquers this muddy ditch over here, that open wheat fiel…

Likewise, people do business with people, not with companies. Assert that “society” is merely an abstraction invoked for political gain to become an individualist.

Re: Against Best Practices

#110

Post by layer8 »

jsbg wrote: post #76

The author sounds like even though they have read extensively about various "best" practices, they did not really gain an understanding of the tradeoffs involved with each one. > “Don’t Repeat Yourself” (DRY) is basically good advice, but sometimes just copy/pasting things is just the more pragmatic thing to do, and not really a big deal. Duplicating code on purpose is not about being pragmatic, it's about recognizin…

The problem with DRY is that it is expressed incorrectly and misleadingly. There is little inherent benefit in avoiding code duplication, and it can do harm when done for the wrong reasons. The actual context is change management. Will the copy of the code likely have to change in the same way as the original? Only then should duplication be avoided. The rule taken literally fails to convey this important precondition and the reasoning behind it. (And so does WET.)
Post reply on HN