Best practices can slow your application down • Hacker News Board

Re: Best practices can slow your application down

#91

Post by Cthulhu_ » Mon, Mar 08, 2021, 1:22 PM UTC

tsimionescu wrote: post #9

beny23 wrote: post #4

In my opinion, the idea that you can have well-tested code OR performance is tosh. 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? And I think the stackoverflow team know it: > Currently, we’re trying to change this. We’re actively trying to write more tests and make our code more testable. I…

You're missing the development time dimension. The point of the SO post is that, given a limited development time, they chose to focus on performance and sacrifice testability. Many years later now, they are choosing the opposite. This doesn't make their initial decision wrong. The site exists and has thrived, and has achieved all of its performance goals. So the decision was correct. If it has now become too hard to…

It's the project management tradeoff; they chose to acquire technical debt in favor of short-term performance, which I'm sure at the time was the way to go (you don't want to be left behind), but now they're paying off the debt, and it sounds like it's a big one.

Reworking existing code is super expensive.

Re: Best practices can slow your application down

#92

Post by arkh » Mon, Mar 08, 2021, 1:25 PM UTC

TDD does not mean "small unit tests at the method level in code".

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.

The excuse of those kind of tests being slow or hard to setup mean only one thing: we have to work on their tooling.

Re: Best practices can slow your application down

#93

Post by nromiun » Mon, Mar 08, 2021, 1:27 PM UTC

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.

Re: Best practices can slow your application down

#94

Post by yowlingcat » Mon, Mar 08, 2021, 1:35 PM UTC

Cthulhu_ wrote: post #89

ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

They're really not selling their codebase or practices to me to be honest. If their system is built like that it might have enough performance to run a top x site on only a handful of bare metal servers, but the article also implies there's a lot of "here be dragons" code - don't touch this, you are not clever enough to test this, and since we don't have tests, you might break it by touching it. Which is just bad pra…

> Which is just bad practice on the one hand, and elitist on the other.

I got exactly the same impression. Making a strawman out of the rest of the market and special-casing yourself always sets off a red flag. It indicates the possibility of a culture could be out of touch with reality, that chooses to rationalize its poor decision rather than facing reality. I wouldn't work at a firm with this kind of culture, it's a liability.

Re: Best practices can slow your application down

#95

Post by iudqnolq » Mon, Mar 08, 2021, 1:43 PM UTC

wccrawford wrote: post #74

azeirah wrote: post #15

Earlier quoted context omitted.

I never got to understand testing. It's a thing that every developer is supposed to know and do well somehow. I always end up writing tests for my programs, but with all the stubs and fixtures and weird stuff I get into hairy problems that I don't understand. Tests are supposed to be helpful, but writing good tests is ridiculously hard. Or maybe it's just because I'm a perfectionist, and I should be happy with crappy…

It's one of those things where people who really believe in it are very vocal and will shout over anyone who dares to think there are any problems. Not everyone loves them. But, as I'm a test-lover, I have to say they're pretty amazing if you can get everyone on-board and writing good tests. As for how hard they are... It depends on how the code is structured. If the code is designed to be testable, it's pretty easy…

I've seen a lot of people say not to design code to be testable. That instead tests should work around whatever shape the code should be in "naturally". Writing this out this seems stupid, it's been pretty influencial on how I code (for the past year or so, I'm a complete beginner).

Re: Best practices can slow your application down

#96

Post by vp8989 » Mon, Mar 08, 2021, 1:45 PM UTC

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/mock anything downstream of me in a fast, isolated and deterministic way. Both locally and in CI.

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 "coverage" is an illusion and the tests add more friction than there really ought to be.

Re: Best practices can slow your application down

#97

Post by 2rsf » Mon, Mar 08, 2021, 1:46 PM UTC

kodah wrote: post #25

When I was an SRE-SE I despised the term "best practices". 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, "Hey, try this, it was useful to us." If it's not a protocol or standard recognized by one of the IEEE, IETF, or ISO then it's a tutori…

The Context Driven Testing community said it [1]

#1) The value of any practice depends on its context.

#2) There are good practices in context, but there are no best practices.

[1] https://www.softwaretestinghelp.com/what-is-context-driven-t...

Re: Best practices can slow your application down

#98

Post by nspattak » Mon, Mar 08, 2021, 1:49 PM UTC

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

Re: Best practices can slow your application down

#99

Post by Veuxdo » Mon, Mar 08, 2021, 2:03 PM UTC

ed_elliott_asc wrote: post #63

I get a bit annoyed by this sort of post, blanket statements like: "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love." Why does the industry seem to love testing? Does the industry love testing? Does this mean you do or don't love testing? It also feels like they wrote this blog post to show off: we write our c# code as if it was c code be…

Is there not a whole industry devoted to selling developers on automated testing?

Re: Best practices can slow your application down

#100

Post by skohan » Mon, Mar 08, 2021, 2:07 PM UTC

tsimionescu wrote: post #12

choeger wrote: post #5

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

Why is that relevant? The fact is that it doesn't (there are good reasons for it, but that is another matter). You can't work with the ideal tools, you can only work with the tools that actually exist. So, with the actual tools, this sacrifice must be made. And now do answer your actual question, the reason is that the languages we use are just not expressive enough, and the compiler doesn't have enough time. If you…

One of the other drawbacks besides performance that I have seen in terms of "making code testable" is that it often hurts traceability. If I am jumping into an unfamiliar codebase, the best case is that I can right click on any method invocation, "go to declaration" and see what code is being executed. Often times in codebases which make heavy use of dependency injection, "go to declaration" takes me instead to some kind of interface declaration, and then I have to figure out which code is actually being executed at runtime.

I feel like this is a very real cost, and is often not accounted for in terms of the tradeoffs discussed in TDD.