Against Best Practices

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.

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?

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