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

71–80 of 158 posts

Re: The Servers Are Burning

#71

Post by TeMPOraL »

stephengillie wrote: post #48

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

Programming would be trivial if things were so simple.

The reality is, that "either it creates revenue by being what users want", or it enables creating more of that later on, or prevents the speed of creating more of that from dropping, or prevents the whole thing from catastrophic errors (like in this article), ...

Those are the trade-offs engineers have to consider daily.

Re: The Servers Are Burning

#72

Post by bunderbunder »

fhood wrote: post #40
mikestew wrote: post #19

Earlier quoted context omitted.

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

> You can't possibly say that with any confidence.

Assuming your module's interface isn't too complicated, it shouldn't be terribly difficult to write a test fixture that fuzzes a module, and verifies that its memory consumption does not go outside a certain bound.

The first round of bugs you'll catch might be design flaws more than true memory leaks - places where the module isn't designed to limit its own memory usage in the face of adverse (or adversarial) input.

Get those pinned down, and then you can use it to catch memory leaks with confidence. Let it run for less time if you're only worried about catching fast leaks, and for more time if you need to catch the slow ones, too.

Re: The Servers Are Burning

#73

Post by chasd00 »

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 worked well enough until they could do something better. Never let perfect be the enemy of good.

Re: The Servers Are Burning

#74

Post by theseatoms »

stcredzero wrote: post #49
theseatoms wrote: post #22

Earlier quoted context omitted.

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.

Interesting. Are there IT consulting firms that specialize in this field of study?

Re: The Servers Are Burning

#75

Post by gred »

> My first employer, the online dating site OkCupid, didn’t harp on testing either. In part, this was because our company was so small. Only seven fellow engineers and I maintained all the code running on our servers—and making tests work was time-consuming and error-prone. “We can’t sacrifice forward momentum for technical debt,” then-CEO Mike Maxim told me, referring to the cost of engineers building behind-the-scenes tech instead of user-facing features. “Users don’t care.” He thought of testing frameworks as somewhat academic, more lofty than practical.

I found this paragraph interesting because my experience with my one-man side project is the opposite: I'm so small, and time is so scarce (I have a separate full-time job), that I can't afford to fix bugs on somebody else's schedule when they find them... instead I spend a large amount of time writing tests up front for new features so that I find the bugs on my schedule (i.e. late at night when I don't have other commitments).

Re: The Servers Are Burning

#76

Post by nradov »

TeMPOraL wrote: post #63
jerkstate wrote: post #53

Earlier quoted context omitted.

I'm not a great programmer, I can't usually write code that does exactly what I expect the first time, so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. This is a lot faster than my old method of writing code that doesn't quite work, and running the whole program over and over with small changes and print statements e…

> so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. In languages like Lisp, this is what you use REPL for. It's an insanely more efficient way of working than the usual edit->recompile->run the whole app again. However, couple of years working with Common Lisp and (recently) Clojure taught me that, even with a good RE…

Even with Java now it's usually possible to modify a running application while you're debugging. Eclipse handles this pretty well.

Re: The Servers Are Burning

#77

Post by nradov »

1_800_UNICORN wrote: post #7

If you're an early-stage startup that's still determining product-market fit, then it's completely fair to eschew tests and accumulate tech debt; you're at a higher risk of running out of runway before you've even proven that your business works. As soon as you have enough users that an outage poses a significant risk to your business, you need to invest in either refactoring to reduce tech debt, or a rewrite. And yo…

Skipping tests generally doesn't allow for creating a working MVP any faster. It's just an illusion.

Re: The Servers Are Burning

#78

Post by bunderbunder »

pjc50 wrote: post #67
bunderbunder wrote: post #44

> 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. W…

> 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 This is an extremely good way of putting it. Doing some of this at the requirements stage if possible can be very helpful too, because you can detect nonsensical or conflicting requirements before you even write a…

I'm rather fond of a book, Specification by Example by Gojko Adzic, that's partially a manifesto for, and partially a guide to, doing this.

Re: The Servers Are Burning

#79

Post by holmberd »

1_800_UNICORN wrote: post #7

If you're an early-stage startup that's still determining product-market fit, then it's completely fair to eschew tests and accumulate tech debt; you're at a higher risk of running out of runway before you've even proven that your business works. As soon as you have enough users that an outage poses a significant risk to your business, you need to invest in either refactoring to reduce tech debt, or a rewrite. And yo…

Easy to say, but unfortunately rarely seen in the wild, depending on the experience of the project manager. Once that product is live and climbing, no owner wants to hear talks about slowing down for reasons of better test coverage or refactoring.

Re: The Servers Are Burning

#80

Post by jpitz »

jerkstate wrote: post #53
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…

I'm not a great programmer, I can't usually write code that does exactly what I expect the first time, so I use unit tests with a debugger in my IDE to run small portions of my new code until it works the way I envisioned it before I started writing it. This is a lot faster than my old method of writing code that doesn't quite work, and running the whole program over and over with small changes and print statements e…

You know, it's so much more vastly important to understand the expectation then it is to get the implementation correct the first time.
Post reply on HN