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

141–150 of 158 posts

Re: The Servers Are Burning

#141

Post by laurent123456 »

TeMPOraL wrote: post #70
mabbo wrote: post #28

Earlier quoted context omitted.

That's not skill, that's luck. If the bug in question had instead leaked every customer's personal data there wouldn't be a $50m company, there'd be a multi-million dollar lawsuit.

I agree with your thinking, but with this particular example: you'd wish. See: every other data leak that happened over the last decade. It seems data leaks are harmless to companies.

I was going to say "not for a dating website", but I see that Ashley Madison still exists despite the massive data leak in 2015 including data from users who had paid to have their data deleted, so yes looks like there's no real fallback for data leaks.

Re: The Servers Are Burning

#142

Post by azeirah »

marcus_holmes wrote: post #119

This is one of the many reasons why I have an allergy to dependencies. I know other people's code is probably better than mine. But I understand mine. If something goes wrong (and something always goes wrong) I know how to fix it. When something goes wrong in someone else's code I either have to start working out how their code works, or report it and sit there like a lemon with a broken system until whoever wrote it…

All I know is that if enough people rely on the same dependency for long enough, the chance of encountering large bugs becomes smaller and smaller. Especially if the dependency has a stable interface.

Good software gets better the more it gets used and abused, so I tend to stay away from small dependencies, they're usually not worth the time.

Re: The Servers Are Burning

#143

Post by usefulcat »

holmberd wrote: post #79
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.

I think the point is more that the slowing down is going to happen anyway if production systems are repeatedly catching on fire and people are afraid to make changes. At that point the difference is how having or not having tests will affect things in the longer term.

Re: The Servers Are Burning

#144

Post by specialist »

TeMPOraL wrote: post #69
pjc50 wrote: post #67

Earlier quoted context omitted.

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

Seconded. I haven't seen it summarized so well before, and the sentence you quoted is the very one that made me favourite that comment.

Metaphorically, this is functional style programming, mapping inputs to outputs, minimize state and side effects.

His conclusion is the money quote for me:

"...your job is finding ways to simplify that input space as much as possible."

I do this. Instinctively? I feel more or less alone in this practice.

My prime motivator is to do less work. Less is more. Concision is a virtue. Blah, blah, blah.

The trouble with my strategy is that simple is hard. Much harder than kanban themed JIRA mediated velocity maximizing slapdashery. Also harder to measure.

So compared to my peers, it looks like I'm moving in slow motion.

To illustrate, someone who fixes the same code pathway multiple times is scored higher than someone (like me) who fixes it (mostly) right the first time.

The tortoise vs the hare.

--

"If I Had More Time, I Would Have Written a Shorter Letter"

  -- Blaise Pascal https://quoteinvestigator.com/2012/04/28/shorter-letter/
"-2000 Lines of Code" http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...

--

Aside: I was a QA/Test manager for a while. I really cared about this stuff, back in the day. Now it seems no one cares.

Re: The Servers Are Burning

#145

Post by specialist »

bunderbunder wrote: post #78
pjc50 wrote: post #67

Earlier quoted context omitted.

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

Thanks for the pro tip. Already reading...

I've been working on a notion tentatively called "example driven development". Use specifications to generate code. Kinda like compiling swagger docs to implement an HTTP server.

My first such effort was using the BA developed HL7 interface documents (swagger for HL7) to code generate our implementations. Worked great.

Re: The Servers Are Burning

#146

Post by jkubicek »

megablast wrote: post #112
toss1 wrote: post #84

Earlier quoted context omitted.

Yup, classic. "...no time/resources to do it right in the first place, but plenty of time/resources to fix it when the customers complain..." I always thought it better to find the bugs in-house before shipping, but so many others don't see it...

You are acting like most bugs aren't already caught in the dev process. No on writes code and just deploys. Writing extra tests that cover everything for a small project that you are working on yourself is a waste of time.

Writing tests for small, personal projects is hugely valuable for me. Running a well-written test lets me iterate much faster than running the entire script or booting up the whole app and poking at the UI.

Re: The Servers Are Burning

#147

Post by holmberd »

usefulcat wrote: post #143
holmberd wrote: post #79

Earlier quoted context omitted.

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.

I think the point is more that the slowing down is going to happen anyway if production systems are repeatedly catching on fire and people are afraid to make changes. At that point the difference is how having or not having tests will affect things in the longer term.

Indeed, but prototypes running in production or running without tests, is a symptom of other underlying problems in the organization. I feel that scope creep and lack of testing goes hand in hand for projects that are poorly managed.

Re: The Servers Are Burning

#148

Post by mikestew »

dawidw wrote: post #136
mikestew wrote: post #64

Earlier quoted context omitted.

You can't possibly say that with any confidence In answer to the original question, I stand behind my answer with 100% confidence. The test infrastructures I build catch memory leaks all of time, and I do not consider it abnormal for them to do so. If you mean to say that I cannot be confident that I have caught all of the memory leaks, well duh, of course I can't. But that's not what was asked, and that's not what I…

> The test infrastructures I build catch memory leaks all of time [...] Could you elaborate on that, please? I'm curious. Thank you in advance!

It would be very specific to the project. For instance, if it's an iOS/Mac project, Xcode has nice profiling tools to catch memory leaks. And of course clang's static analyzer as well. What I'm working on now is embedded Linux, so valgrind and some test suite to exercise the code.

But in general, no matter the project, you need a few key pieces:

1. A test suite that thoroughly exercises the code. You'll need this for...

2. A tool such as valgrind to watch memory as your tests in #1 run. Build time, ad hoc, stick in the pipeline anywhere you like.

3. A static analyzer to take a first pass at the code and say, "hmm, this might leak/crash/kill puppies." So, yeah, the order is off as this should be the first thing you do. It can run on your dev machine or on the build machine. Expect lots of false positives.

(optional) 4. A code coverage tool to make sure you're not missing key pieces of code that need exercise.

Re: The Servers Are Burning

#149

Post by pritambaral »

pwg wrote: post #117
TheCapn wrote: post #8

(Off Topic -- Rant regarding Webpage) Can I take a short moment to bitch about "sidebar" frame or whatever the hell this domain is using? The webpage looks like a fluid single frame but the left side is static. The browser page has a scrollbar but I need to have my mouse over the correct div before my scroll wheel will move the page, its a bit aggravating since there's no visual break between the "sidebar" and the co…

I just turned off CSS in Firefox (View menu -> Page Style -> No Style) and the fixed sidebar was no more and the odd scroll bar behavior was gone.

I used Firefox's Reader Mode.

Re: The Servers Are Burning

#150

Post by Jeff_Brown »

freekh wrote: post #29
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…

Anecdoctally this happened to me the other day in my Haskell backend: had a recursive function (in the IO monad) that every ten second would take a connection of my connection pool (and since it was recursive) would not give it back to the pool. Of course it was a stupid bug, but it was hard to figure out because it would take a while before it got to that point and once it was there every call to the backend would b…

This makes another argument for Haskell, because the language allows you to isolate the non-pure code into a thin top layer. That makes debugging much easier than it would be if the complexity of IO extended all the way down through your app's subfunctions.
Post reply on HN