Live data from Hacker News

Against Best Practices

arp242.net

61–70 of 218 posts

Re: Against Best Practices

#61

Earlier quoted context omitted.

> Follow best practices unless you can give a reason not to. Cargo culting much? I'd say, follow best practices only if you can say exactly why it is best practice.

I don't think so. For example, If I'm writing something in a programming language I don't know by heart, I start by following the best practices recommended by the language authors, then start to flex them when they become less useful, until I hit a nice pitfall which these best practices are designed to avoid. This allows me to start faster, and be in a better shape in short term. Then I can flex advice more and mor…

I also read the language tutorial first. But if they don't explain their best practices (and often the explanation is simple), I don't care much for them.

Re: Against Best Practices

#62

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'm one of the devs not aware of the SWEBOK. Searching the internet all I can find is links to "the guide to SWEBOK". https://ieeecs-media.computer.org/media/education/swebok/swe... But, you know, I want the whole ordeal. I want the SWEBOK, not the "how to read the SWEBOK". Where can I find it?

I think that is what you want. From Wikipedia:

> In 2016, the IEEE Computer Society kicked off the SWEBOK Evolution effort to develop future iterations of the body of knowledge. The SWEBOK Evolution project resulted in the publication of SWEBOK Guide version 4 in October 2024.

So the thing called "SWEBOK Guide" is actually the reference text for SWEBOK.

Re: Against Best Practices

#63
post #30

Software around us is quite terrible, so it’s kind of obvious that one shouldn’t follow “best practices” that led to this state of things.

Maybe if people didn't follow best practices their software would be terrible-er? Guardrails for hard things doesn't imply no guardrails would make it easier.

Re: Against Best Practices

#64

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'm one of the devs not aware of the SWEBOK. Searching the internet all I can find is links to "the guide to SWEBOK". https://ieeecs-media.computer.org/media/education/swebok/swe... But, you know, I want the whole ordeal. I want the SWEBOK, not the "how to read the SWEBOK". Where can I find it?

It looks like SWEBOK Guide, guide to the SWEBOK, and SWEBOK are all used interchangeably. I wonder if they have a chapter on naming conventions.

Re: Against Best Practices

#65

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'm one of the devs not aware of the SWEBOK. Searching the internet all I can find is links to "the guide to SWEBOK". https://ieeecs-media.computer.org/media/education/swebok/swe... But, you know, I want the whole ordeal. I want the SWEBOK, not the "how to read the SWEBOK". Where can I find it?

[deleted]

Re: Against Best Practices

#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 necessarily do harm because they offer bad advice, they do harm because they are advocated for by zealots and the inexperienced.

My first reaction is how unfortunate it is that this particular developer has found himself in the presence of bad engineers and the inexperienced.

But then, the argument is automatically self-defeating. Why is the rest of the article even worth reading, if he states upfront what his arguments are and those arguments are very easy to refute?

It is deeply irrational to judge the merits of an idea based solely on who is advocating for that idea.

My advice to the author is to reflect on the types of positions that he accepts, the ones that have him so put off by the people that he works with that he is openly writing about abandoning what he admits could be sound engineering practice, solely based on who that advice is coming from and how it is being delivered.

Developing software is complicated. It is constant problem solving. When solutions to problems come about, and we abstract those solutions, it is quite easy for individuals to misapply the abstraction to an inappropriate concrete. To drop context and try to retrofit a lousy solution because that solution was appropriate to a slightly different problem. But at the end of the day, these abstractions exist to try and simplify the process. Any time you see a "best practice" or design pattern acting as a complicating force, it is not doing its job. At that point you can either be objective and exercise some professional curiosity in order to try and understand why the solution adopted is inappropriate ... or you can take the lazy way out and just assume that "best practices" are the opinions of zealots and the inexperienced who blindly follow because they don't know any better.

Re: Against Best Practices

#68
“Best practices” have nothing to do with engineering. They are a marketing concept. They are a kind marketing better known as bullying.

In every case where you want to say “best practice” there is a better alternative, which is to say “practice.” The concept of best is never needed or warranted, because practices are not subject to rigorous testing and review.

I have been an independent consultant and trainer since 1999 and not once have I taught or recommended a best practice.

I do have many opinions. I call them: opinions. I think my opinions are the best, but I can’t think of any reason that anyone else beyond my wife and dog should think so.

Re: Against Best Practices

#69

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) conventions (especially ones designed by committee), and too many options.

Having systems, tools, and components that don't change often with respect to compatibility and are formally-verifiable far beyond the rigor of seL4 such that they are (basically) without (implementation) error would be valuable over having tools lack even basic testing or self-tests, lack digital signatures that would prove chain-of-custody, and being able to model and prove a program or library to a level such that its behavior can be completely checked far more deeply in "whitebox" and "blackbox" methods for correctness would prove that some code stand the test of time. By choosing lesser numbers of standard language(s), tool(s), and component(s) it makes it cheaper and easier to attempt to do such.

Maybe in 100 years, out of necessity, there will be essentially 1 programming language that dominates all others (power law distribution) for humans, and it will be some sort of formal behavioral model specification language that an LLM will generate tests and machine code to implement, manage, and test against.

Re: Against Best Practices

#70

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…

"Engineering industry" is a misnomer. Other engineering areas have the same issues with best practices we have, industries apply best practices with a great amount of success (but not to totality).

Usually, engineering creates best practices for the industries to follow.

Post reply on HN