Against Best Practices

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.

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.

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.

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 (not a "just so" explanation that skips several steps).

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

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

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

100%… a best practice in other traditional engineering practices help us work within the state of the art. They’re the accumulated wisdom and experience of engineers that came before us.

There are plenty of them that help us write concurrent code that avoids common deadlock situations without having to resort to writing proofs every time. Someone already did the work and condensed it down into a rule to follow. Even if you don’t understand the underlying proof you can follow the rule and hope that everything will shake out.

What I find we struggle most with is knowing when we actually need to write the proof. Sometimes we bias ourselves towards best practices and intuition when working it out formally would be more prudent.

This. They’re supposed to represent the state of the art which is constantly evolving.

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

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

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

The confusion is because "BOK" is not "book of knowledge" but "body of knowledge". So a "guide" as a canonical source kinda makes sense.

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

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.

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

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

This! "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... )

I’m not sure folklore and handwaving is worse than relying on some sort of bible some mysterious organisation wrote as your source of truth.

Hmhm, just like “AWS is recommending serverless, so we should serverless everything!”

Never mind that AWS recommends what is good for AWS, not us.

In general that is true, I think. Even if it doesn’t apply in all circumstances, it’ll apply in most.

It’d be ideal if you could identify when it doesn’t work. But in the absense of that applying it everywhere is still a net positive.

I agree with you, I think you're describing the same sort of person I was thinking of in the second paragraph of this post: https://joshduff.com/2022-02-07-eschatology-of-software.html

Makes me think as well of the best practices in development & project management methodologies.

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

If everyone follows that then every decision will be bikeshedded to death. I think part of the point of the concept of "best practices" is that some ideas should be at least somewhat entrenched, followed by default, and not overturned without good reason.

Ideally your records of best practices would include a rationale and scope for when they should be reexamined. But trying to reason everything out from first principles doesn't work great either.

I could tell you the moon is made of cheese. If I'm wrong about it being made of cheese, does that mean the moon doesn't exist?

It strikes me that, if a decision can be bikeshedded to death, it's not, generally speaking, an important decision.

I definitely sympathize with the thrust of the article. I think the reality is somewhere in the middle: best practices are useful short-cuts and people aren't always idiots for suggesting them. I've worked with folks who insist on Postel's law despite security research in recent years that suggest parsers should be strict to prevent langsec attacks, for example. In those cases I would refute leniency...

Although I also do work in fintech and well... card payment systems are messy. The legal framework covers liability for when actors send bad data but your system still has to parse/process/accept those messages. So you need some leniency.

It does drive me up the wall sometimes when people will hand-wave away details and cite maxims or best-practices... but those are usually situations where the details matter a great deal: security, safety, liveness, etc. People generally have the best intentions in these scenarios and I don't fault them for having different experience/knowledge/wisdom that lead them to different conclusions than I do. They're not idiots for suggesting best practices... it's just a nuisance.

That's what I mean about the rejection being too strong. It should be considered that best practices are often useful and helpful. We don't have to re-develop our intuitions from first principles on every project. It would be tedious to do so. But a healthy dose of skepticism should be used... especially when it comes to Postel's Law which has some decent research to suggest avoiding it.

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

Well calling something a bikeshed is implicitly claiming that it's not so important. Often the specific choice is not very important, but making a choice rather than not making one is important. And while an effective organisation would not allow important decisionmaking to get derailed, many organisations are ineffective.