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

151–160 of 187 posts

Re: Best practices can slow your application down

#151

Post by hinkley »

travisjungroth wrote: post #85
CraigJPerry wrote: post #26

Earlier quoted context omitted.

>> If the tests are too complex for anyone to change the code, the the code is too complex In enterprise software, the pattern i see is specifically coupling rather than garden variety complexity. There’s a really pervasive idea that unit testing means 1:1 mapping of test class to production code class. To put it another way, there’s this really common but terrible idea that tests should map to your current implement…

> A related issue is no one ever deletes tests. I think this is a huge problem. I’m not sure why it exists. “If we have more tests it will be harder to change the code.” is an argument people make sincerely. Then... just delete the tests. If your argument against having these tests is you can imagine a point where they become a burden, just keep in mind that it’s really, really fast to delete code. “Untested” is a st…

I joke that we should make the team watch one of those Hoarder TV shows, but it's a Tears of a Clown sort of situation.

Try telling people that you're deleting a flaky test and they'll stop working on their current story to try to stop you. It's as predictable as the phases of the moon.

Re: Best practices can slow your application down

#152

Post by ploxiln »

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…

What does StackOverflow really have left to deliver, though? They made a fairly snappy and robust web application which has very popular functionality, that serves giant boatloads of traffic, with a relatively small team of developers and a relatively small cluster of servers. They didn't have twitter-fail-whale like incidents as far as I recall.

It seems they proved that you don't need lots of good unit tests, you can out-perform the whole industry without that. (I say this as someone who doesn't care for Windows or C# - I still recognize superb execution.) At this point they just feel sheepish and apologetic about it.

Re: Best practices can slow your application down

#153

Post by iudqnolq »

wccrawford wrote: post #133
iudqnolq wrote: post #95

Earlier quoted context omitted.

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

To me, the shape the code should be is largely the same as easily-testable code anyhow. You want functions that do small, self-contained things so that you can reason about them efficiently. That also makes them easier to test. Yes, sometimes you end up with a monstrous function because of requirements... But then, that's how you have to test it anyhow. That said, some of the more intense testing things, like depende…

Small functions, sure.

The most common case of this I've run into is should I use dependency injection just for testing. My function creates a Frob and interacts with it. By default Frobs persist changes to a DB and sync over the network. I don't want to do that in a test. Now I need to pass a frobFactory of (FrobConfig) -> Frob to my function.

Sure in theory I could use my new configurability for all sorts of things, but in practice I only end up using the alternative path in tests.

When do you not end up needing something like this?

Re: Best practices can slow your application down

#154

Post by jdsully »

orclev wrote: post #124
arcturus17 wrote: post #69

Earlier quoted context omitted.

I also found the "or similar practices that the industry seems to love" coming across as a bit vague and even arrogant. On the other hand, I think that they have earned bragging rights - we're talking about a site that has massive scale and reach, and has a reputation for being a very efficient system. I appreciate that people like them share their views, even if they are contrarian and a touch arrogant. > they chose…

It's important to remember Joel Spolsky, one of the founders of stackoverflow is an old school Microsoft guy that managed the Excel team before starting his own company. He has always been a bit of a Microsoft fanboy, and used to advocate a lot for VB as a serious language back before it got swallowed by .Net and turned into a less powerful syntax for C#. The fact they chose C# isn't surprising at all given that. It…

He never managed the Excel team and he didn't write code for the product. He was a PM and wrote the spec for VBA. An accomplishment to be sure but not much different than all the other great individual contributors Excel has had over the years.

Re: Best practices can slow your application down

#155

Post by beny23 »

BlargMcLarg wrote: post #27
beny23 wrote: post #19

Earlier quoted context omitted.

I think that the “we can go quicker by not testing” is a fallacy. If you do TDD right it will make you quicker, not slower in the short term. Not just the long term...

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…

Ok, my bad for “I think” - I should have said: in my 30 year experience I’ve yet had to come across a system were good tests were a hindrance to performance. I’ve had many a time where complex investigations into performance problems were uncovered by systematic and automated tests.

If performance is a main goal, then surely TDD with performance in mind will give you a better advantage

Re: Best practices can slow your application down

#156

Post by orclev »

jdsully wrote: post #154
orclev wrote: post #124

Earlier quoted context omitted.

It's important to remember Joel Spolsky, one of the founders of stackoverflow is an old school Microsoft guy that managed the Excel team before starting his own company. He has always been a bit of a Microsoft fanboy, and used to advocate a lot for VB as a serious language back before it got swallowed by .Net and turned into a less powerful syntax for C#. The fact they chose C# isn't surprising at all given that. It…

He never managed the Excel team and he didn't write code for the product. He was a PM and wrote the spec for VBA. An accomplishment to be sure but not much different than all the other great individual contributors Excel has had over the years.

Perhaps I should have said he was a manager on the Excel team.

Re: Best practices can slow your application down

#157

Post by stonemetal12 »

klingon78 wrote: post #117
stonemetal12 wrote: post #107

Earlier quoted context omitted.

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 r…

I meant upgrading application frameworks, OS, etc., so it’s not a red herring. Those can inflict a lot of changes if you have a lot of tests affected.

Thus automated test time + automated test maintenance is usually less than manual test time + manual test maintenance. Mostly because execution time for automated tests is so much shorter than manual execution time that the higher cost of automated test maintenance is recouped and then some.

The only way for framework\OS changes to impact that is if they happen often enough to make automated test maintenance "weigh" more than all the time saved by no longer having to manually run your test suite.

Re: Best practices can slow your application down

#158

Post by orclev »

josephg wrote: post #32
klodolph wrote: post #29

Earlier quoted context omitted.

It’s also a strategy to isolate failures and to use resources efficiently. I’ve had a very positive experience working on a team that deployed a collection of microservices. That said, it was large scale, and most of the “micro” services were only conceptually micro; they were large in terms of resource usage. We also had excellent tooling.

There are strategies other than microservices to break a problem up into small pieces, manage resources and isolate failures. I've consistently heard good things about Erlang/OTP.

It's because Erlang abstracts the difference between distributed and centralized services. In Erlang everything is message passing, and Erlang doesn't much care if the components passing messages are running on the same server or multiple ones in a DC, it will route the messages either way. In many ways Erlang is the ultimate micro-service, to the point where the entire language is built around it.

Re: Best practices can slow your application down

#159

Post by jdsully »

orclev wrote: post #156
jdsully wrote: post #154

Earlier quoted context omitted.

He never managed the Excel team and he didn't write code for the product. He was a PM and wrote the spec for VBA. An accomplishment to be sure but not much different than all the other great individual contributors Excel has had over the years.

Perhaps I should have said he was a manager on the Excel team.

He did not have a management role. PMs write specs and talk to the customers. That time was also very much the "cowboy coding" era so part of the job was convincing devs they should implement it how he spec'd because he couldn't force them. I think that's part of why he was so popular with his blog aimed at programmers, he had lots of time honing his persuasive technique.

Re: Best practices can slow your application down

#160

Post by sgtnoodle »

vp8989 wrote: post #83
sgtnoodle wrote: post #68

Earlier quoted context omitted.

Adding test coverage might indeed destroy their performance, in that they might expose where their system's bottlenecks are and realize that they've been focusing on the wrong things. When it comes to performance optimizations, folks' intuitions are almost always wrong. It's important to actually test and measure stuff like that. I think it's true in general that modern CPUs are insanely fast at executing code within…

It's hilarious that you are skeptical of the competence of the SO core devs. You should do a little further reading, there is lots of content available online from the core devs who actually "do the work" there (ie, not the people who wrote this fluffy blog post).

I'm basing my opinion on reading the article. The claims that were made are consistent with what I've experienced working with folk with relatively limited software engineering skill. I don't think that's an unfair or mean thing to say. The whole premise of the article is to try and convince me that not following best practices can be a good thing. To me, the article seemingly reads as defensive, as if the author is actually trying to convince themselves or their coworkers that they aren't to blame for an accumulated decade of technical debt.

In reality, there's no blame to assign when tackling tech debt. Real projects are messy. Folk defer work for short term gains at the cost to their future self. Growing tech debt is just an eventual engineering problem to tackle like anything else. Best practices are distilled wisdom intended to keep those sorts of problems from growing out of control.

Re: the competency of the SO core devs, they very well could and probably are solid within their domain. Not knowing anything about them though, I think it's possible that they're a bit siloed off in their knowledge. If a lot of their core team were there from the beginning of the project and were relatively inexperienced at the time, they may not have ever invested their time into developing test tooling. In some ways it's very impressive that they're able to keep that large of a project going with so little testing infrastructure.

Post reply on HN