Best practices can slow your application down • Hacker News Board

Re: Best practices can slow your application down

#101

Post by helsinkiandrew » Mon, Mar 08, 2021, 2:11 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…

> the article also implies there's a lot of "here be dragons" code

Agreed, fine if enough of the core developers are around, but if the company merged, the app needed to be extended or altered significantly, or some of the underlying technology stack is deprecated/becomes unsupported keeping things working will be very expensive.

Re: Best practices can slow your application down

#102

Post by thrower123 » Mon, Mar 08, 2021, 2:17 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…

You seem to be searching out a reason to be offended by this rather bland, vanilla blog post that simply explains what they did.

Re: Best practices can slow your application down

#103

Post by kybernetikos » Mon, Mar 08, 2021, 2:21 PM UTC

marcosdumay wrote: post #78

beny23 wrote: post #14

Earlier quoted context omitted.

It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I’d argue that they were successful despite their approach not because of it. I actually have a lot of time for their design choices (monolith, scale up as much as possible, etc, not everything needs to be distributed microservices) but to find doing that by sacrificing testing is surprising. I really don’t think it’s a mode…

> It’s always going to be orders of magnitude more difficult/expensive to retrofit testability. I can't take this any other way than a huge overstatement. I'm yet to find any such example where retrofitting it is orders of magnitude harder. Worst case it requires understanding the entire system again, and adding instrumentation here or there. That can be almost as hard as writing the entire system again, but usually…

I read that statement as orders of magnitude more difficult/expensive to retrofit testability as opposed to making the system testable at the start, not as opposed to creating the system.

Re: Best practices can slow your application down

#104

Post by mcv » Mon, Mar 08, 2021, 2:22 PM UTC

acd wrote: post #20

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. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…

This was never a surprise to anyone. The goal here isn't speed, but maintainability.

Re: Best practices can slow your application down

#105

Post by Frost1x » Mon, Mar 08, 2021, 2:22 PM UTC

vp8989 wrote: post #88

jbjbjbjb wrote: post #81

Earlier quoted context omitted.

It’s a peeve of mine too. The phrase ‘best practice’ is thrown around far too often and it can be used as a way to shortcut objective analysis.

It's candy for beginner/intermediates who want to sound like they know what they are talking about.

It works very well. I've seen all sorts of monstrosity code bases developed under the guise of "best practices" where the original developer or team jettisoned away and now a business doesn't know what to do with it. They often can't abandon it because it's critical to their work but they also can't go forward as is because of all sorts of issues they're encountering. Application maintainence is where empirical data tests designs, best practices, and new shiny. Unfortunately, those who create these messes never see anything but greenfields while they perpetuate poor cargo cult mentalities.

The tech and terminology often dazzles less savvy businesses and they're happy until problems start to arise.

Re: Best practices can slow your application down

#106

Post by amardeep » Mon, Mar 08, 2021, 2:27 PM UTC

sgtnoodle wrote: post #62

BlargMcLarg wrote: post #27

Earlier quoted context omitted.

Emphasis on " I think ". Unfortunately, your thinking hasn't had a whole lot of support, as studies have found both findings in favor of and arguments against TDD, both short term and long term. Furthermore, I would ask you to name the contexts in which you believe TDD to be better in the short term. Things differ when a lot of critical and non-trivial data-modifying code exists compared to an interface which changes…

I wouldn't have thought "testing is always good" would be a controversial claim! I could make the claim that dogs shouldn't eat potting soil and most folk would probably agree with me. I don't have any proof that it's actually bad though. My dog gobbled up some potting soil today and he will probably be just fine. I still think he's a doofus, though. I personally write significantly higher quality code, faster, when…

That kind of unit tests sounds great. I always reach for writing tests for eg. for library functions. Though I tend to skip when testing some app functionality which basically requires stubbing/mocking tons of services, and feeding them what output to expect on what input - in those cases, I don't find tests or TDD very helpful.

I find a lot of value in unit tests for isolated logic testing and in functional tests for end to end testing. Still that leaves a lot of code in a modern web application (like stackoverflow) where I find tests don't provide enough bang for buck.

Re: Best practices can slow your application down

#107

Post by stonemetal12 » Mon, Mar 08, 2021, 2:30 PM UTC

klingon78 wrote: post #87

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…

Something not mentioned but is a much bigger problem than performance for most is that if you write too many tests, you may be unable to easily upgrade/update to newer versions without a significant amount of work to update all of the tests. You’re right to call out performance as a reason for testing. Unfortunately, though, it’s usually not that easy. A problem not found in testing may be the result of inexperience…

Isn't that a bit of a red herring? Either I have automated tests that will take time to update every once in a while, or I have manual regression tests that I have to run for every code change. The automated test path seems to be the much less time intensive path, depending on how often you make big changes.

On the other hand I really believe 100% unit test coverage is a bit of a waste of time. Unit tests should be reserved for algorithmic\calculative code, more mundane code logging\carting data from a to b type code should be covered by automated black box testing.

Re: Best practices can slow your application down

#108

Post by ehutch79 » Mon, Mar 08, 2021, 2:34 PM UTC

acd wrote: post #20

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. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…

Netflix is doing it! So it must be right for my 1 developer internal app with a dozen users.

Re: Best practices can slow your application down

#109

Post by jugg1es » Mon, Mar 08, 2021, 2:39 PM UTC

anon1253 wrote: post #22

acd wrote: post #20

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. Depending on your organization scale of course, but for many smaller shops, there is a significant performance overhead of going over the network. Ie a Single binary running Rust/Go/Java/NodeJs vs…

My hope is that the same realization will eventually come to web developers as well. A well written desktop application is much faster, and typically more stable, than a web app that's hosted ... well who can tell where. This isn't to say that web applications don't offer tremendous value, but it is definitely a trade-off worth considering sometimes.

I love building desktop applications but they come with their own set of complications related to installation and DLL-hell.

Re: Best practices can slow your application down

#110

Post by bxrxdx » Mon, Mar 08, 2021, 2:43 PM UTC

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.