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

41–50 of 158 posts

Re: The Servers Are Burning

#41

Post by 3pt14159 »

I appreciated this article because I so infrequently get to hear from people that hold this view of testing, which I do not share.

To me, the importance of tests are a function of the consequence of failure and the likelihood that failure will happen. It's a question of hazard and risk.

One thing to realize is that code that lasts longer is more likely to fail because the people and libraries that support it are prone to change and assumptions can break. So risk goes up over time.

The other thing to realize is that code that's part of a growing product is going to impact more people if it fails. There might be only 400 users today, but 40k three years from now. So hazard goes up over time.

When I heard the technical debt arguments I try to triage them into "grows with the company" vs "doesn't grow with the company" so I can figure out what to accept as debt and what to pay. A complex deploy infrastructure doesn't scale. Just SSHing into a box and doing the deploy manually is just as fine for 100 users as it is for 1000. But tests do. So I write lots of tests; especially for ACL and I punt on the infrastructure stuff until I absolutely need to.

Note that this leaves aside the entire argument over whether tests slow stuff down. I think that on average they make refactors easier and features slower, so for the projects I'm on it's a wash. But even if I grant the point my conclusion wouldn't change. Tests are good.

Re: The Servers Are Burning

#42

Post by twic »

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…

That moral seems related to a meme floating around that Mean Time To Recovery is more important than Mean Time Between Failures. I think it came from, or through, John Allspaw:

https://www.kitchensoap.com/2010/11/07/mttr-mtbf-for-most-ty...

It's popular with a lot of people i know, because it's one of those ideas that's counterintuitive but believable, and so makes you feel really smart for knowing it.

Re: The Servers Are Burning

#43

Post by ddebernardy »

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.

Outrageously unprofessional as it may be, they probably ended up laughing on their way to the bank when they got purchased by match.com.

Re: The Servers Are Burning

#44

Post by bunderbunder »

> in order to write effective tests, a programmer had to know all of the ways that a piece of software could fail in order to write tests for those cases

No.

In order to write effective tests, a programmer has to think of the piece of software's entire input domain, carve it up into a set of equivalence classes, and then determine what the expected behavior should be for a piece of input from each of those classes. With more careful testing at their boundaries, so that you can root out edge and corner cases.

The results of those tests will then find the ways your software can fail for you.

Thinking about it this way, it starts to become clear that a huge part of your job is finding ways to simplify that input space as much as possible. Simplifying at this stage makes getting it right so much easier. The fewer special, edge, and corner cases you allow in the first place, the fewer you have to code for, the fewer you have to test for, the fewer you might accidentally miss, and the fewer others might accidentally run afoul of.

This, incidentally, is the key reason why it's good to take some time to define all your tests before you start writing your implementation. I'm not necessarily a huge advocate for "red green refactor", but I do think that at least identifying all your test cases before you ever start implementing can potentially save you boatloads of time, by helping you recognize opportunities to simplify your design before you get locked into an unnecessarily complicated one by a couple hours or days (or months) of sunk cost.

It's also the real reason (IMO) why functional programming - as a style, not a kind of language - is such a valuable discipline. The challenge with programming in an imperative style is that it turns your module's entire past history into one of the inputs you need to consider, and that turns your test and specification surface into something that is just so much bigger. Considering that it opens up the possibility of injecting bugs into a routine without ever actually editing the routine itself, or even any of the functions it calls, it's possibly even fair to say that it's unbounded.

Re: The Servers Are Burning

#45

Post by macintux »

ddebernardy wrote: post #39
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

That's one reason I really like functional programming: it's easier to test pure functions, vs code with side effects that requires you to look at the internal state afterwards.

Re: The Servers Are Burning

#46

Post by adrianN »

3pt14159 wrote: post #41

I appreciated this article because I so infrequently get to hear from people that hold this view of testing, which I do not share. To me, the importance of tests are a function of the consequence of failure and the likelihood that failure will happen. It's a question of hazard and risk. One thing to realize is that code that lasts longer is more likely to fail because the people and libraries that support it are pron…

Without automated deploys, how do you know that what you deploy is actually what you tested?

Re: The Servers Are Burning

#47

Post by stcredzero »

adrianN wrote: post #24
stcredzero wrote: post #14

Earlier quoted context omitted.

Given that technical debt is quite hard for non-technical people to quantify, why wouldn't we expect that most startups would tend to accrue technical debt?

Startups accrue so much financial debt, adding some technical debt on top doesn't really make a difference.

Technical debt doesn't accrue in a linear fashion. Instead, it's synergistic. Up to a certain point, it's a noticeable drag. Past that point, there is a change in the difficulty incurred.

In the article, the combination of some "you're-supposed-to-just-not-do-that" with:

>If (the database throws an error) { do nothing }

resulted in a major mishap.

Re: The Servers Are Burning

#48

Post by stephengillie »

> “Users don’t care.”

This is the counter to every technical bikeshedding post. Either it creates revenue by being what users want, or it's a waste of time. And people seem to love wasting time instead of delivering.

Re: The Servers Are Burning

#49

Post by stcredzero »

theseatoms wrote: post #22
stcredzero wrote: post #14

Earlier quoted context omitted.

Given that technical debt is quite hard for non-technical people to quantify, why wouldn't we expect that most startups would tend to accrue technical debt?

Can anyone quantify technical debt? Best case is something resembling a medical diagnosis.

I think that could be enough. Actuaries have a good idea about when you are likely to die in the next two years. Basically, when you are old and your medical costs suddenly double. Doctors use the same sort of inductive reasoning for their prognosis. The industry probably collectively has all the information to put together useful actuarial tables on technical debt, but it's all silo'd in individual companies.

Re: The Servers Are Burning

#50

Post by pjc50 »

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…

> responsibility to write high-quality software

Since GDPR, there's now an effective legal minimum of quality; you need to protect user data and keep it accurate.

Post reply on HN