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

The Servers Are Burning

logicmag.io

Post reply on HN
Print view View original

31–40 of 158 posts

Re: The Servers Are Burning

#31

Post by sneak »

matt2000 wrote: post #18

When making something new where you're not sure of the value yet, I've found that you can get 80% of the benefits of unit tests with around 20% of the tests you'd write to get "full coverage." My main goal is to at least have the code run in an expected way and produce an expected result. This doesn't catch everything, but it does seem to catch enough problems to be worth it for the time invested. Edit: I should ment…

Yes to the last! Whenever bughunting my first step is to reproduce the issue in a failing test. This has the benefit of me being sure I know what is failing and how, but also crystallizes then knowledge and experience into the repo for future engineers (or future me) to know the most common/practical ways things break in the real world. It is also marginally useful for catching regressions, if the test is clever/general enough.

Re: The Servers Are Burning

#32

Post by [deleted] »

hnruss wrote: post #16

After reading the introduction, I thought that the author was going to use a story of software failure as an example of why you should write unit tests, or at least why you shouldn't deploy untested software. However, the moral of the story was essentially: "software is so complicated that it is bound it break, so you have to be good at fixing it". While that is certainly true, I think that developers have a responsi…

[deleted]

Re: The Servers Are Burning

#33

Post by jhayward »

jschwartzi wrote: post #27
hnruss wrote: post #16

After reading the introduction, I thought that the author was going to use a story of software failure as an example of why you should write unit tests, or at least why you shouldn't deploy untested software. However, the moral of the story was essentially: "software is so complicated that it is bound it break, so you have to be good at fixing it". While that is certainly true, I think that developers have a responsi…

> However, the moral of the story was essentially: "software is so complicated that it is bound it break, so you have to be good at fixing it". While that is certainly true, I think that developers have a responsibility to use whatever tools they can to write high-quality software. I actually disagree that we have a responsibility to write high-quality software. As engineers our job is to create software that is good…

> As engineers our job is to create software that is good enough for the task at hand

This is the essence of engineering. As the saying goes, "Any fool can build a bridge that won't fall down. It takes an engineer to build a bridge that just barely won't fall down."

In other words an engineer's contribution is not perfection, it is being able to know the difference between "good enough" and "needs more work" and to apply that knowledge to meet time, cost, and material constraints.

Re: The Servers Are Burning

#34

Post by dxhdr »

noelwelsh wrote: post #10

How could such a tiny change have such an outsized impact on the site? “That same story happened so many different times,” my old boss David told me. “Someone launched a small, relatively innocuous change that did one of the millions of unexpected things it could have done, which then happened to break some part of the site, and then bring it all down—sometimes bring it down to the point where we couldn’t recover it…

> If a function is "referentially transparent" or "pure" it can't do anything unexpected.

Sure it can; at a minimum all functions consume compute resources. A tiny change in a "pure" JavaScript function could lead to cascading deoptimizations that destroys performance and compromises service availability. For example, changing 0.0 to 0 could do it.

Re: The Servers Are Burning

#35

Post by TheDong »

mreome wrote: post #20
noelwelsh wrote: post #10

How could such a tiny change have such an outsized impact on the site? “That same story happened so many different times,” my old boss David told me. “Someone launched a small, relatively innocuous change that did one of the millions of unexpected things it could have done, which then happened to break some part of the site, and then bring it all down—sometimes bring it down to the point where we couldn’t recover it…

While I can understand some of the benefits of functional programming within a single sub-system, or within academic research, I struggle to understand how pure functional programming can address the need for the large amounts of state information and abstraction layers required for a large scale system. I work with systems where (large/numerous) sub components require very specialized domain knowledge to understand…

> Do you have anything that explains this complex topic?

> Something that assumes I don't know anything about the pre-requisite topic would be helpful

Unfortunately the only way to gain a deep understanding of the powerful tools functional languages do give you is to gain a deep understanding of functional paradigms.

Me saying "Monads can help with state abstractions" doesn't help you.

The fact that large non-trivial applications have been written in haskell should be enough evidence that this is possible.

The fact that the majority of people involved in such endeavors have claimed that it made their code safer and easier to refactor and had relatively few bugs should be enough evidence that it's a good idea.

The fact that those who decry it more often than not do not know the subject should give their criticisms no weight.

I don't see why you need any more evidence that you should simply learn functional programming so that you may first-hand answer your own question.

Re: The Servers Are Burning

#36

Post by JackFr »

andrenotgiant wrote: post #4
JackFr wrote: post #2

Wow. 1. We don't test. 2. We don't code review (or rather if we do, we do it so poorly swallowed exceptions don't raise red flags.) That's an outrageously unprofessional software process.

An outrageously unprofessional software process that created a product worth $50M! https://techcrunch.com/2011/02/02/match-com-acquires-online-...

Created a product worth $50M because of their software process or despite there software process.

Re: The Servers Are Burning

#37

Post by KingMob »

JackFr wrote: post #2

Wow. 1. We don't test. 2. We don't code review (or rather if we do, we do it so poorly swallowed exceptions don't raise red flags.) That's an outrageously unprofessional software process.

I'm sure the OkCupid folk are nice people but it was:

1) founded by mathematicians and an academic, and 2) written in C++, with a custom templating language

Even giving them the benefit of the doubt that the core matching algorithm warranted C++, the whole site really shouldn't have been built that way.

I'm really not surprised there's poor technical decision-making there.

Re: The Servers Are Burning

#38

Post by skybrian »

swalsh wrote: post #25
JackFr wrote: post #2

Wow. 1. We don't test. 2. We don't code review (or rather if we do, we do it so poorly swallowed exceptions don't raise red flags.) That's an outrageously unprofessional software process.

It's a free dating service. They have a responsibility to respect their users' data privacy, but the rest kind of doesn't matter. Eventual stability is more profitable than eventual release if you're not a Bank or making self driving cars.

Yeah, I expect the devs at Ashley Madison told themselves that too.

It's possible to build sandboxes where security or privacy bugs are contained, but the shops that don't care much about software quality are probably not doing that.

It seems a little too easy for people building a social app to tell themselves they're just building a toy that doesn't matter. Their users might disagree after they get hacked.

Re: The Servers Are Burning

#39

Post by ddebernardy »

matt2000 wrote: post #18

When making something new where you're not sure of the value yet, I've found that you can get 80% of the benefits of unit tests with around 20% of the tests you'd write to get "full coverage." My main goal is to at least have the code run in an expected way and produce an expected result. This doesn't catch everything, but it does seem to catch enough problems to be worth it for the time invested. Edit: I should ment…

The big problem I've noticed when reading unit tests in various projects is that they frequently test the implementation rather than the outcome:

https://softwareengineering.stackexchange.com/a/304910/24932

Re: The Servers Are Burning

#40

Post by fhood »

mikestew wrote: post #19
plopz wrote: post #17

Earlier quoted context omitted.

Do testing frameworks normally catch memory leaks?

Mine do.

You can't possibly say that with any confidence. I literally just finished reproducing a memory leak caused by an insane combination of circumstances. This was not something valgrind or any similar tool would find. It was not something that any rational human being would have thought to write tests for.

Once code is no longer synchronous, and tasks are being juggled around and swapped between, it becomes virtually impossible to predict what might cause this sort of bug.

Post reply on HN