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

121–130 of 218 posts

Re: Against Best Practices

#121

Post by malfist »

layer8 wrote: post #105

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…

I like to use the term "golden path" instead of best practices.

In a golden path, lots of others have gone before you and figured out all the nuance. But this doesn't mean the path is the best one for you, but does mean you should have a good reason for starying from it

Re: Against Best Practices

#122

Post by worik »

No.

I've worked too often with people who think they know better

They do not

Straw men do not change the fact that "best practices" , especially the ones quoted, are very good.

No sensible person is saying "never use globals". We caution you to think very carefully before you do, only for truly global state.

I am suffering from inherited code, written by a very good programmer, who got lazy with globals and comments. Too many of the former, too few of the later. What a nightmare

This article is arrant nonsense

Re: Against Best Practices

#124

Post by coding123 »

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…

The army that is conquering is carrying best practice weapons, wearing best practice boots, best practice fatigues, best practice tanks, trucks, etc.

They're best practice aiming, shooting, walking, communicating, hiring (mercs), hiding, etc...

The people that are in the weeds are just doing the most simple things for their personal situation as they're taking over that granite rock or "copse of lush oak trees".

It's easy to use a lot of words to pretend your point has meaning, but often, like KH - it doesn't.

Re: Against Best Practices

#125

Post by recursive »

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 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.

It sounds to me like they did understand the tradeoffs. But that they were being brow-beaten to apply "best practices" that were inapplicable because of the tradeoffs.

Re: Against Best Practices

#126

Post by recursive »

worik wrote: post #122

No. I've worked too often with people who think they know better They do not Straw men do not change the fact that "best practices" , especially the ones quoted, are very good. No sensible person is saying "never use globals". We caution you to think very carefully before you do, only for truly global state. I am suffering from inherited code, written by a very good programmer, who got lazy with globals and comments.…

> No sensible person is saying "never use globals".

Maybe so, but still, plenty of people are saying it.

Re: Against Best Practices

#127

Post by godelski »

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…

  > No army has ever conquered a country
Napoleon and his army would like to have a word with you…

I get the analogy but I think it can be made a lot better, which will decrease people who dismiss it because they got lost in where the wording doesn’t make sense. I’m pretty confident most would agree that country A conquered country B if country B was nothing but fire and rubble. It’s pretty common usage actually. Also, there’s plenty of examples of countries ruled by militaries. Even the US president is the head of the military. As for army, it’s fairly synonymous with military, only really diverting in recent usage.

Besides that, the Army Corp of engineers is well known to build bridges, roads, housing, and all sorts of things. But on the topic of corp, that’s part of the hierarchy. For yours a battalion, regiment, company, or platoon may work much better. A platoon or squad might take control of a building. A company might control a hill or river. But it takes a whole army to conquer a country because it is all these groups working together, even if often disconnected and not in unison, even with infighting and internal conflicts, they rally around the same end goals.

By I’m also not sure this fully aligns with what you say. It’s true that the naive only talk at abstract levels, but it’s common for experts too. But experts almost always leak specifics in because the abstraction is derived from a nuanced understanding. But we need to talk in both abstractions and in details. The necessity for abstraction only grows, but so does the whole pie.

https://en.wikipedia.org/wiki/Military_organization

Re: Against Best Practices

#128

Post by srmatto »

The author sort of goes against his own advice but not diving into the specifics of why he doesn't like certain things. I get that such a piece would be longer, take more time and effort, and would draw more argumentation but that's what he's asking for in the piece itself.

Re: Against Best Practices

#129

Post by godelski »

coding123 wrote: post #124
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…

The army that is conquering is carrying best practice weapons, wearing best practice boots, best practice fatigues, best practice tanks, trucks, etc. They're best practice aiming, shooting, walking, communicating, hiring (mercs), hiding, etc... The people that are in the weeds are just doing the most simple things for their personal situation as they're taking over that granite rock or "copse of lush oak trees". It's…

This is frequently not true. There’s examples all through history of weaker and poorer armies defeating larger ones. From Zulus, to the American Revolution, to the great Emu wars. Surely the birds were not more advanced than men armed with machine guns. But it’s only when the smaller forces can take advantage and leverage what they have better than others. It’s best practices, but what’s best is not universal, it’s best for who, best for when, best for under what circumstances

Re: Against Best Practices

#130

Post by michael1999 »

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 like SWEBOK, but I don't understand your point.

SWEBOK seems the opposite of that. A body of knowledge is not at all the same thing as a best practice. The only unapologetic best practice in SWEBOK is that professionals should be familiar with every topic in SWEBOK. Definitely not that you _should_ do everything in the book.

The book is quite sophisticated in this. It explicitly separate the technical knowledge from the judgments of which, when, and where to apply it. Most occurrences of "best practices" in the text are quoted, and are references to other works and describe the need to choose between different best-practice libraries depending on context. Others are part of a meta-conversation about the role of standards in engineering. Very little of SWEBOK is promoted as a "best practice" in itself.

Here's a quote from SWEBOK v4, 12-5

> Foremost, software engineers should know the key software engineering standards that apply to their specific industry. As Iberle discussed [19], the practices software engineers use vary greatly depending on the industry, business model and organizational culture where they work.

Post reply on HN