Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Best practices can slow your application down

stackoverflow.blog

Post reply on HN
Print view View original

71–80 of 187 posts

Re: Best practices can slow your application down

#71

Post by mcv »

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…

Lines like that[0] sound like the goal is to please the industry, without questioning why the industry loves these things. It's good to question established best-practices, but it's also good to understand why they are best-practices.

[0] "With our code base, you won’t be able to easily do test driven development or similar practices that the industry seems to love."

Re: Best practices can slow your application down

#72

Post by FridgeSeal »

ivanbakel wrote: post #28
anon1253 wrote: post #22

Earlier quoted context omitted.

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.

>My hope is that the same realization will eventually come to web developers as well. What makes you think that they don't already realise this? What suggests to you that web developers work on webapps for performance reasons, rather than familiarity with the technology or ease of development (or cross-platform support, or lack of user barriers, etc)?

The insane proliferation of SPA’s, electron apps and the general attitude of “dev time is more important than app performance” of the front-end community suggests performance isn’t a real concern.

Re: Best practices can slow your application down

#73

Post by marcosdumay »

jtsiskin wrote: post #47
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…

That’s true, but also networks can be fast. https://colin-scott.github.io/personal_website/research/inte... It can be faster to read over the network than to read from a hard drive.

Well, yes, it can, and people exploit this in large datacenters all the time. That's one of the reasons people get huge, expensive machines full of disks that do nothing else.

But none of this applies to your run of the mill REST web service.

Re: Best practices can slow your application down

#74

Post by wccrawford »

azeirah wrote: post #15
hinkley wrote: post #6

Earlier quoted context omitted.

Very, very few people know how to make cheap tests. I have one guy who writes fixtures that couples all of his tests. When I need to add functionality, first I have to replace his fixtures with basic stubs, just so I can add another bit of functionality. And we have two people who copy his coding style. Probably to fit in. I think, based on my own experiences and working with people learning to write tests, that 'sim…

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 to write simple tests. Integrations get a little tougher, but as long as you know what the other side should return, it's pretty easy to stub them out.

Testing existing code that was not designed to be testable is a lot harder. It typically will introduce a lot of side effects and won't be properly separated. It can be tested, but IMO just isn't worth the hassle. I've found that you end up spending as much time writing tests as you would have fixing the bugs that arise... And code doesn't get used forever. Modern dev culture insists that someone call for a rewrite eventually, no matter how good the code is, unless you're working in a system that already has decades of legacy code.

My advice would be to start a small project of your own (or wait until you get a new project at work that's from scratch) and write tests from the start. It'll teach you a ton about testing and help you get the system off the ground quickly and solidly. I did this for the last big server-side system I wrote and the tests helped tremendously. The bugs that QA found were generally things that I didn't consider or that they designed wrong. The tests helped me get everything working and keep it working while they changed all kinds of things.

Sadly, once that project ended up in the hands of other devs, the tests slowly died and I was the only one trying to fix them. I eventually went to another project for a while and came back to find the tests basically didn't work at all, and they died completely at that point. But they did their job at the start, and were totally worth it.

Re: Best practices can slow your application down

#75

Post by raverbashing »

If someone says to me "something is a best practice" my question is: according to whom?

Because 95% of "Best Practices" around are just somebody's opinion disguised as a rule.

"Oh TDD is a best practice now" only if it's to sell more books. Yes I love unit testing, but to do it how it's the "best practice" please

Do you have an objective metric that's improved by your "best practice"?

SO itself is a great example. They're still on IIS+C# and it works for them. What if they didn't stop chasing the new fad or "best practice", like Kubernetes

Re: Best practices can slow your application down

#77

Post by yen223 »

jtsiskin wrote: post #47
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…

That’s true, but also networks can be fast. https://colin-scott.github.io/personal_website/research/inte... It can be faster to read over the network than to read from a hard drive.

... as long as the server isn't itself reading from a hard drive!

Re: Best practices can slow your application down

#78

Post by marcosdumay »

beny23 wrote: post #14
tsimionescu wrote: post #9

Earlier quoted context omitted.

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 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 it's much easier, because all the exploratory work has been done and tests are merely formal.

I'd say that correcting the bugs you'll find with those tests is way more work than adding the tests, and maybe they would be easier if they were discovered earlier. But again, the "orders of magnitude more work" is an overstatement.

Re: Best practices can slow your application down

#79

Post by marcosdumay »

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…

Standards are for interoperability. If you try to get best practices out of them, you are set for a world of pain.

But I do agree, the hype of the day isn't a best practice either. And just the term "best practice" without any qualifier or context is already a sign of incompetence.

Re: Best practices can slow your application down

#80

Post by blowski »

thesimon wrote: post #38
bottled_poe wrote: post #23

Earlier quoted context omitted.

I don’t think anyone is claiming that microservices are inherently faster. Instead it is a strategy to keep software loosely coupled and enable very large systems to be built by parallel teams while maintaining productivity and quality both technically and organisationally. That said, I’m a strong proponent of monolithic architectures until scale becomes a problem.

A quite good strategy I've found is moving one bounded context (from domain-driven design) into one microservice. You don't end up with lots of network calls for one use case and still have good maintainability.

I think, theoretically, that's close to what you're "supposed to do". The problem is genuinely identifying and limiting those bounded contexts in such a way that business and technology sticks to consistently.
Post reply on HN