Best practices can slow your application down

Reading between the lines, it sounds like maybe they know they've dug themselves into a very expensive hole to dig out of. I've jumped head first into codebases that made the same excuse, and to me it seems severely limiting in terms of long term productivity. There are definitely benefits to simple, "static" singleton interfaces, and such interfaces aren't inherently incompatible with mocking and dependency injection. It does mean you likely need a layer of indirection somewhere, but if you're sweating the overhead of a single vtable lookup or explicit function pointer call on code that's internally accessing a non-trivially sized data structure, how are you even able to measure it?

The problem is that a handful of foundational static interfaces never got unit tested, and all the other code calls directly into them, so nobody anywhere wrote any unit tests because they couldn't (without touching foundational code that's unsafe to modify for lack of unit tests.) The first step in the right direction is to fix the foundation. This is terrifying for the folk that have been around a while and cemented in their assumptions about risk because they've tiptoed around modifying portions of the codebase for years. Luckily, a big benefit of static singleton interfaces is that it's very easy to modify them with O(n) developer time (where n is the number of references in the codebase). So, you just have to buckle down and get your hands dirty. You're pretty much guaranteed to find at least one latent bug in any old piece of code that you unit test, and so folk start to see the merits of the test coverage and it becomes easier to prioritize refactoring more and more ancient and scary code. After you've done it to half a dozen or so disjoint pieces of code, something magical happens. Suddenly, the vast majority of the codebase becomes easily unit testable.

It would be nice to see the effect on the environment as part of the decision-making process for deciding whether to optimize versus scale.

I think developers have an innate desire to fix performance issues as optimization produces a better understanding of the code and the problem and developers would like to solve the problem in the best possible way. And it helps to know that the problem won’t bite again later.

- True best practices mainly refer to standards, and this list is very slowly updated, unlike the number of false ones;

- It's often used for marketing purposes, which works well, but doesn't always imply quality;

- Since this spreads fast, we often have things at the places where they do not fit, but squeezed into, because it's the best, so we must have it;

- Forms a wrong mindset to rely upon someone else's experience instead of learning and gaining own understanding.

In the end, we have tons of inapplicable or controversial information to filter, which doesn't make things better, in my opinion. Sharing is great but we should do it responsibly.

It's also a bit funny to watch how the best practices suddenly become the worst.

Edit: formatting

The idea that you can have either best practices or performance is a false dichotomy. Testing can be used to help track down performance issues. It can help you write code faster and prevent breakages. It should not slow you down.

Best practices inside a codebase should not sacrifice performance. If you have to do that to conform to some structural ideal, you don’t do it. I would love to see this supposedly untestable code.

Stackoverflow may contain lots of great dev knowledge, but it’s also a weird site that discourages participation and entrenches old answers. I am unsurprised that the devs themselves are a proverbial old dog that can’t learn new tricks.