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

81–90 of 218 posts

Re: Against Best Practices

#81

Post by mrkeen »

grey-area wrote: post #4
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…

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

>> inexperienced programmers who lack the ability to judge the applicability

In other words, the author knows better than you.

The author could have put forward precedent, principles, or examples. But instead he chose to make it about the people (inexperienced), not his arguments.

Re: Against Best Practices

#83

Post by toast0 »

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…

> How other engineering industries deal with this phenomena? Why those approach do not work with programming?

A lot of engineering discipline is a way to prevent engineered works from causing unintentional injury, physical or fiscal.

Most software development is far away from physical injury. And fiscal injury from software failure is rarely assigned to any party.

There's no feedback loop to push us to standardized process to cover our asses; we'd all prefer to do things our own way. It's also pretty hard to do convincing studies to determine which methods are better. Few people are convinced by any of the studies; and there's not been a lot of company X dominates the industry because of practice Y kinds of things, like you see with say Toyota's quality practices in the 80s and 90s.

Re: Against Best Practices

#84

Post by [deleted] »

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…

[deleted]

Re: Against Best Practices

#85

Post by eichi »

I want engineers to think about the best for the project but I let engineers talk about the best of implementation because it's better than doing irrevant things.

Re: Against Best Practices

#86

Post by dkarl »

Living through the 2000s was enough to give me a permanent aversion to "best practices." So many things that we look back on in horror were smugly and haughtily justified using those words.

There was a culture of best practices zealots that had an uncanny resemblance to organized religion. All the answers have been written down for us, and everything that goes wrong is because of arrogant, misguided people who decided to trust their own fallible thoughts instead. Their faith was strong enough to survive any project, no matter the outcome.

Re: Against Best Practices

#87

Post by betenoire »

Only software engineers pretend best practices exist outside of any useful context.

- small localized team vs big distributed team

- bug fixes and incremental improvements vs green field poc

- saas vs system scripts

Context matters, and if people aren't giving you the context in which they deem practices to be "best", they are myopically wrong

Re: Against Best Practices

#88

Post by dkarl »

heisenbit wrote: post #10

While 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 pla…

The alternative is to accept that every solution has drawbacks and trade-offs. Best practices were an attempt to codify design standards that would be equivalent to "buying IBM" in the sense of the old phrase, "Nobody gets fired for buying IBM."

That was always a bad idea. Often the best choice in one context would be a bad choice in other contexts. You don't want an engineer in a 20-person startup making decisions like they're at Google, or vice-versa. You have to take responsibility for deciding what's best for a particular problem in a particular context, without looking for the cover of "everybody does it this way."

Re: Against Best Practices

#89

Post by yCombLinks »

mrkeen wrote: post #81
grey-area wrote: post #4

Earlier quoted context omitted.

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

>> inexperienced programmers who lack the ability to judge the applicability In other words, the author knows better than you. The author could have put forward precedent, principles, or examples. But instead he chose to make it about the people ( inexperienced ), not his arguments.

The point is there are not rules that are always applicable. Dry is right sometimes, and sometimes it's not.

Re: Against Best Practices

#90

Post by davorak »

TehShrike wrote: post #77
0xbadcafebee wrote: post #75

Earlier quoted context omitted.

I don't think anyone has ever thought that best practices will always benefit you. Nothing always works every single time in every single case. This whole thing is really silly and obvious. Of course you shouldn't blindly follow advice without thinking. But not following advice just because it might not always be right is also a bad idea. My advice: In general , you should follow good advice from experienced people .…

> I don't think anyone has ever thought that best practices will always benefit you. Whenever a "best practice" or "convention" has been presented to me, that is how it has been framed. (...it is best practice, therefore, it will definitely benefit you to follow it)

I do not know what context this happened to you in, but in the context of building something quickly, learning, while not being an expert in an area, best practice are a common crutch.

In many work places either they do not have time or at least think they do have time to think things through 100% for themselves from first principles so they depend on best practices instead.

That makes sense to me and I would expect better results on average with using best practices than rejection of best practices in the above context.

That said I try to work on things where I am not always in the above context, where thinking things through end to end provides a competitive advantage.

Post reply on HN