6 ms·
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 soft
by agentultra 2y ago
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 out of hand either and people recommending them aren’t idiots.
Update: one problem with “best practices,” that I think the article might have unwittingly implied is that most software developers aren’t aware of SWEBOK and are repeating maxims and aphorisms they heard from others. Software development is often powered by folklore and hand waving.
- javcasas 2y agoI'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/swebok-v4.pdf 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?
- desbo 2y agoI 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.
- GranPC 2y agoIt looks like SWEBOK Guide, guide to the SWEBOK, and SWEBOK are all used interchangeably. I wonder if they have a chapter on naming conventions.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- marcosdumay 2y agoThe books that encode some standardized Xbok are always named "The guide to the Xbok". The actual BOK isn't supposed to have a concrete representation. It's not supposed to be standardized either, but standard organizations always ignore that part.
- agentultra 2y agoThis. They’re supposed to represent the state of the art which is constantly evolving.
- marcosdumay 2y agoWell, literally the "state" as in what is the knowledge that everybody shares. We usually call that by something closer to "minimum common denominator". What people usually call "state of the art" is the best knowledge that is reasonably well known. That is out of scope. If you take a look on this one, it's full of stuff that we knew not to use on the 20th century. This is typical.
- rfrey 2y agoThe confusion is because "BOK" is not "book of knowledge" but "body of knowledge". So a "guide" as a canonical source kinda makes sense.
- deleted 2y ago[deleted]
- TehShrike 2y agoI 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 (not a "just so" explanation that skips several steps).
- 0xbadcafebee 2y agoI 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. If enough experts say this is the best way to do something, you should probably do that, most of the time. But that advice will never trend on HN because it isn't clickbait or extreme, and requires using your noggin.
- TehShrike 2y ago> 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)
- davorak 2y agoI 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.
- layer8 2y agoWhile 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 https://news.ycombinator.com/item?id=41907412
- ozim 2y ago*However they shouldn’t be rejected out of hand either and people recommending them aren’t idiots.* Also it shouldn't be taken for granted that best practice is always "best/good" - there definitely are idiots recommending best practices.
- michael1999 2y agoI 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.
- agentultra 2y ago> I don't understand your point In my view best practices emerge from a body of knowledge (or sometimes from the practice and wisdom of others that haven't been documented/accepted/etc yet) and are "shortcuts." I'm not defending Postel's Law; I agree that, after years of practice and research, it leads to security issues and surprises. However, the point is that these kinds of principles don't arise out of people's heads and become accepted wisdom for nothing; they're usually built off of an implied (or explicit) body of knowledge. Does that make sense?
- michael1999 2y agoSure. Best practices develop by choosing practices to match your context out of a defined body of knowledge. But SWEBOK is very clear that "best practices" are context specific - they are radically different forces and solutions in video games as compared to chemical engineering control systems. There's no such thing as a "best practice" absent a context. The footnotes in SWEBOK point off in a million directions saying "go look over there for best practices for YOUR context".
- SoftTalker 2y agoTo put it simply, best practices are, at best, context-dependent. Best practices for avionics software are not the same as best practices for a CRUD form on your mailing-list signup page. And to be fair, the best practices for designing a bridge or a skyscraper are not the same ones for designing a doghouse.
- jrs235 2y agoThis! "Best practice" depends on the circumstances. Are "micro services" a best practice? What about "monolithic architecture"? Those choices are not best practices in and of themselves but may be best practices when considering organization/dev team size, application user count, computational demands on the application/system, etc. What are the goals and vision of the future? Let's future-proof and pre-optimize for problems we don't currently have nor will likely have! (And don't get me started on the number of folks that dream about "we're going to need to be able to scale!" for a fairly simple CRUD app that will most likely be used by hundreads, maybe thousands, or users and realistically need 100's of "simple" requests per second (most likely per minute... )
- seadan83 2y agoMakes me think as well of the best practices in development & project management methodologies.
- Aeolun 2y agoI’m not sure folklore and handwaving is worse than relying on some sort of bible some mysterious organisation wrote as your source of truth.