Best practices can slow your application down

I get a bit annoyed by this sort of post, blanket statements like:<p>&quot;With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love.&quot;<p>Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don&#x27;t love testing?<p>It also feels like they wrote this blog post to show off: we write our c# code as if it was c code because we are better than all of you.<p>The fact is that every application is different, they chose to use a language that back in 2000&#x27;s wasn&#x27;t designed for performance and so they paid the price of using it for performance and didn&#x27;t want to pay the scale out price.<p>Is their codebase testable, yes completely. Will adding unit tests to their code destroy their performance? no, there are always ways to make it testable and fast. Maybe in a few years we will see a &quot;We thought testing was impossible but we made it work and also keep our codebase fast&quot;.

In my opinion, the idea that you can have well-tested code OR performance is tosh.<p>If you don’t have good testing and do it regularly how can you refactor your application for speed if you’re not going to be sure that you’re going to introduce a regression?<p>And I think the stackoverflow team know it:<p>&gt; Currently, we’re trying to change this. We’re actively trying to write more tests and make our code more testable. It’s an engineering goal we aim to achieve, but the changes needed are significant.<p>This makes it sound like a lofty goal but I think it just sounds more like. “Oh crap, we’re sitting on a mountain of tech debt”<p>No I know you can’t always expect to arrive at a project and find the sunny uplands of TDD and continuous delivery but if you do get to “optimised for speed” code (to me that’s a synonym for tech debt that’s slowing down delivery) all you can do is slowly add what should have been done in the first place (tests).

Somewhere down the line, developers will start to realize that single applications running in the same server memory and CPU cache will run much faster than Micro services applications that makes api calls over the network.<p>Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network.<p>Ie a Single binary running Rust&#x2F;Go&#x2F;Java&#x2F;NodeJs vs distributed Microservices applications.

When I was an SRE-SE I despised the term &quot;best practices&quot;. Teams would come in telling me all about the new best practice with serverless, Kubernetes, secrets storage, or whatever. It was almost always like someone took a magnificent full Lego set and snapped off a wall and was like, &quot;Hey, try this, it was useful to us.&quot; If it&#x27;s not a protocol or standard recognized by one of the IEEE, IETF, or ISO then it&#x27;s a tutorial with a strong opinion. Nothing wrong about that, but just know you&#x27;re often reading a strong opinion, not a standard.<p>&quot;Best practices&quot; almost always come out of some business or project explaining what tested best with their circumstances. That alone tells you everything you need to know. Invest in a testing process which exposes the most critical parts of your application&#x2F;infrastructure, attempt to overwhelm or exploit them, and you&#x27;ll find out what your best practices need to be real quick. Those best practices may work at other companies but not nearly as well as if they invested in their own testing processes that are as or more rigorous than yours.

&gt; it’s no silver bullet: your software is not going to crash and burn if you don’t write your tests first, and the presence of tests alone does not mean you won’t have maintainability issues<p>This is not what tests are for. Tests rarely catch bugs for the first version of their code. They often catch bugs in modifications to that code, and any bugs that aren&#x27;t caught can be added as a test. Tests are like checkpoints in video games. They guarantee that you don&#x27;t regress past a point. Over time you build up so many checkpoints that your code is hard to break without a test failing. It&#x27;s an evolutionary process.

The article makes the excuse that static (singleton) interfaces are inherently simpler and less resource intensive enough for it to be worth skipping regression testing (because testing that style of code is hard.)<p>Reading between the lines, it sounds like maybe they know they&#x27;ve dug themselves into a very expensive hole to dig out of. I&#x27;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, &quot;static&quot; singleton interfaces, and such interfaces aren&#x27;t inherently incompatible with mocking and dependency injection. It does mean you likely need a layer of indirection somewhere, but if you&#x27;re sweating the overhead of a single vtable lookup or explicit function pointer call on code that&#x27;s internally accessing a non-trivially sized data structure, how are you even able to measure it?<p>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&#x27;t (without touching foundational code that&#x27;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&#x27;ve tiptoed around modifying portions of the codebase for years. Luckily, a big benefit of static singleton interfaces is that it&#x27;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&#x27;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&#x27;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.

I have to admit I would far rather work on a conceptually simple codebase, that has been kept fast and light with minimal testing, than to work on a conceptually muddled codebase with 100% testing.<p>Performance is a feature, and so is being able to reason through a codebase.<p>Being able to fit all the pieces in your head is a feature, but not so snappy.

TDD does not mean &quot;small unit tests at the method level in code&quot;.<p>It means you code your test cases before you implement the functionalities. Those tests can (and IMO should) be behavior tests: then you can rip out all your code and replace it with whatever you like, even off-the-shelf software and your test suite will still run.<p>The excuse of those kind of tests being slow or hard to setup mean only one thing: we have to work on their tooling.

One thing that stood out to me was they wouldn&#x27;t need necessarily need to optimize for performance if they didn&#x27;t choose a stack whose costs increase massively as you scale.<p>In many applications things like having a testable, easy-to-read, well-structured codebase can trump performance, and it&#x27;s often worth sacrificing a bit of performance if it means it&#x27;s easier to refactor and build new features.

This should be obvious. Writing well-structured, decoupled, modular code can make you lose track of performance concerns. And since no one likes to write things more than once, so there&#x27;s only &quot;one shot&quot; at writing the application, people tend to err on the side of &quot;well-structured&quot;, because hey, who&#x27;s gonna fore you for following best practices?

So, if this article actually showed me how writing modular testable code slowed down their application, and how they fixed it, that would be really interesting.

Fully agree with the article.<p>&gt; &quot;Best practices, not required practices&quot;<p>Is a thing mentioned from the article that I think many people forget. It also not only applies to programming or coding but rather to most things in life. Just because someone says it is best doesnt mean it is for you in your situation.

I think the industry should re-evaluate whether unit testing ought to still be the dominant testing paradigm. With Docker and things like WireMock I can fake&#x2F;mock anything downstream of me in a fast, isolated and deterministic way. Both locally and in CI.<p>There is so much accidental complexity cruft and ceremony involved with the writing of unit tests and making things unit testable. In a lot of cases, the &quot;coverage&quot; is an illusion and the tests add more friction than there really ought to be.

It sounds like the team is interested in adding more automated tests, but are blocked by static singletons, which have high performance but also high coupling, resulting in poor testability.<p>I&#x27;m sure they&#x27;ve heard of test libraries like MS Fakes and Pose; I wonder if these libraries would let them maintain high performance, and only introduce the required layer of indirection during testing?

I think that this is more of a marketing post than a technical post. That said, I really wish people do not promote bad practices, they are already too well established :)

These sound like some poor excuses to me.<p>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.<p>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.<p>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.

I’m just thinking about how much CO2 emission was spared by optimizing performance instead of scaling horizontally.<p>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.<p>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.

I am not saying that you have to test every single piece of your code, but IMO sooner or later you will be forced to do so. Weather it is through the type checker (static or gradual), unit tests or manual tests is up to you. Unit tests just make this a little easier. You can replicate unit tests every time you commit (testing for bugs) without writing them down.

What are we supposed to do with this article with no code and no benchmarks? It reads like baseless justification for bad code.

Don’t fully understand the argument here. One the one hand they claim they built a successful solution with minor problems without test driven development or a lot of unit tests.<p>On the other hand they claim to really like tests and have it as a goal to do more of them.<p>But this is a contradiction. If they successfully built a large site with minimal testing then why exactly do they need all these unit tests?<p>If they where successful without test driven development then why do they need TDD?<p>To be cool?<p>It sure what to make of this. The argument seems inconsistent. If I had major success without best practices I would have proclaimed loudly that those practices are BS. But these guys seem to want it but ways.

I find anyone using the term “best practices” usually doesn’t understand them.

Duplicate of [<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26381640" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26381640</a>}]

They noted in the post that they had a fixed number of servers and those servers had fixed performance characteristics. A lot of what they say applies specifically to that situation.<p>The problem is that they make broader claims about the validity of best practices (design, OOP, unit testing). Those best practices apply just fine to the status quo, where you can scale out easily and maintainability is more important than performance.

I don&#x27;t understand the claim that replacing &quot;polymorphism and dependency injection&quot; with &quot;static fields and service locators&quot; reduces allocations.<p>I would expect that getting rid of dependency injection would allow you to convert a virtual method call to a direct method call, and replace a constructor argument with a static field reference, but I don&#x27;t see the connection to allocation.<p>Anybody understand this?

I think the problem with this article and their approach will be more visible when super star developers start to leave the company. If they are all the same people from the very beginning, yes, throw lots of practices out of the window because people know the codebase very well. But once they are out, there will be a mountain of tech-debt. They even try to make it testable.

Clearly adding further constraints can only worsen performance. I would code according to best practices except for cases where it’s possible to infer them implying tight bottlenecks. Then profile the code and if circumventing best practices results in a meaningful performance increase, do that.

This is almost obvious for a company made up of senior, capable developers. Hopefully no one else takes this as advice because things are already bad enough without giving people license to forgo testing or design for loose coupling.

The argument against Tests sounds like a tooling problem to me. Why shouldn&#x27;t a compiler be able to optimize the modular approach to the same code that a monolithic approach yields?

I&#x27;ve seen this pattern more often than not, but as the person joining the company later and having to fix other people&#x27;s mess who either left or moved into management.

&gt; .NET - so fast you can&#x27;t do dependency injection

Like in anything else when someone says &quot;best&quot; the only response should be &quot;best for what?&quot;

To be fair, many of the ASP.NET best practices are completely insane.

If someone says to me &quot;something is a best practice&quot; my question is: according to whom?<p>Because 95% of &quot;Best Practices&quot; around are just somebody&#x27;s opinion disguised as a rule.<p>&quot;Oh TDD is a best practice now&quot; only if it&#x27;s to sell more books. Yes I love unit testing, but to do it how it&#x27;s the &quot;best practice&quot; please<p>Do you have an <i>objective</i> metric that&#x27;s improved by your &quot;best practice&quot;?<p>SO itself is a great example. They&#x27;re still on IIS+C# and it works for them. What if they didn&#x27;t stop chasing the new fad or &quot;best practice&quot;, like Kubernetes