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

Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

flightglobal.com

Post reply on HN
Print view View original

201–210 of 311 posts

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#201

Post by kelnos »

philsnow wrote: post #192
ericjmorey wrote: post #99

Earlier quoted context omitted.

Which company deployed a chaos monkey deamon on their systems? Seemed to improve resiliency when I read about it.

At Google, the global Chubby cell had gone so long without any downtime that people were starting to assume that’s it was just always available, leading to some kind of outage or other when the global cell finally did have some organic downtime. Chubby-SRE added quarterly synthetic downtime of the global cell (iff the downtime SLA had not already been exceeded).

For those of us who haven't worked at Google, what's "Chubby" and what's a "cell"?

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#202

Post by kelnos »

Arainach wrote: post #183
lesuorac wrote: post #181

Earlier quoted context omitted.

But then when somebody else has the issue they make a new bug and any data/investigation from the old one is basically lost. Like what's wrong with having 1000 open bugs?

In becomes functionally impossible to measure and track tech debt. Not all of those issues are tech debt - things which will never be fixed don't matter. Put another way: you're working on a new version of your product. There are 900 issues in the tracker. Is this an urgent emergency where you need to shut down feature work and stabilize? If you keep a clean work tracker where things that are open mean work that shou…

That's absurd. Closing those issues doesn't make them go away, it just causes you to forget them (until someone else reports them again and someone creates a new issue, losing all the previous context). If you just leave them open, some will eventually get fixed, many will not, and that's fine.

The decision between feature work vs. maintenance work in a company is driven by business needs, not by the number of bugs open in the issue tracker. If anything, keeping real bugs open helps business leaders actually determine their business needs more effectively. Closing them unfixed is the equivalent of putting your head in the sand.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#203

Post by kelnos »

lmm wrote: post #180
Shorel wrote: post #108

Earlier quoted context omitted.

I'm in total disagreement with your last paragraph. In fact, I can't see how it follows from the rest. Software can have defects, true. There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Closing something for spurious psychological reasons seems detrimental to actual engineering and it doesn't actually avoid any real problem. Let me repeat that: ignoring a problem doesn't ma…

> There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Realistically, no, they won't. If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. Certainly by the time someone gets around to trying to fix the bug, the ticket will be far enough out of date that that person will not be able to trust it. There is zero value in…

> If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed.

That's quite a big assumption. Every company I've worked at where that was the case had terrible culture and constantly shipped buggy crap. Not really the kind of environment that I'd use to set policy or best practices.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#204

Post by polskibus »

I would’ve thought that in flight industry they got the „business key” uniqueness right ages ago. If a key is multi-part then each check should check all parts not just one. Alternatively, force all airport codes to be globally unique.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#207

Post by lmm »

kelnos wrote: post #203
lmm wrote: post #180

Earlier quoted context omitted.

> There are finite resources, true. So keep the tickets open. Eventually someone will fix them. Realistically, no, they won't. If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. Certainly by the time someone gets around to trying to fix the bug, the ticket will be far enough out of date that that person will not be able to trust it. There is zero value in…

> If the rate of new P0-P2 bugs is higher than the rate of fixing being done, then the P3 bugs will never be fixed. That's quite a big assumption. Every company I've worked at where that was the case had terrible culture and constantly shipped buggy crap. Not really the kind of environment that I'd use to set policy or best practices.

If you're in the kind of environment where you fix all your bugs then you don't have a ballooning bug backlog and the problem never arises. I've worked in places that fixed all their bugs, but to my mind that was more because they didn't produce the kind of product that has P3 bugs than because they had better culture or something.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#208

Post by hughdbrown »

jp57 wrote: post #9

FYI: nm = nautical miles, not nanometers.

Wow, I read this article because I could not understand how two labeled points on an air path could be 3600 nanometers apart. Never occurred to me that someone would use 'nm' to mean nautical miles.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#209

Post by lelanthran »

tovej wrote: post #190
chrisweekly wrote: post #178

Earlier quoted context omitted.

True, but it's the exception that proves the rule; it's also the same company responsible for delivering a staggeringly high percentage of internet video, typically without a hitch.

That's not what an exception proving a rule means. It has a technical meaning: a sign that says "free parking on sundays" implies parking is not free as a rule. When used like this it just confuses a reader with rethoric. In this case netflix is just bad at live streaming, they clearly haven't done the necessary engineering work on it.

> That's not what an exception proving a rule means. It has a technical meaning: a sign that says "free parking on sundays" implies parking is not free as a rule.

So the rule is "Free parking on Sundays", and the exception that proves it is "Free parking on Sundays"? That's a post-hoc (circular) argument that does not convince me at all.

I read a different explanation of this phrase on HN recently: the "prove" in "exception proves the rule" has the same meaning as the "prove" (or "proof") in "50% proof alcohol".

AIUI, in this context "proof" means "tests". The exception that tests the rule simply shows where the limits of the rules actually are.

Well, that's how I understood it, anyway. Made sense to me at the time I read the explanation, but I'm open to being convinced otherwise with sufficiently persuasive logic :-)

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#210

Post by d1sxeyes »

lmm wrote: post #191
d1sxeyes wrote: post #76

Earlier quoted context omitted.

So we were talking about excess deaths, which means that supporting your argument with a paper that argues that a previous finding of excessive deaths was flawed is probably not the strongest argument you could make. Increased number of injuries but not deaths could be, for example, (purely making things up off the top of my head here) due to higher levels of distractedness among average drivers due to fear of terror…

> which results in more low-speed, surface-street collisions, while there’s no change in high speed collisions because a short spell of distractedness on the highway is less likely to result in an accident. That's not a remotely plausible model though. There are recorded cases of e.g. 1.6 seconds of distractedness at high speed causing a fatal collision. Anything that increases road injuries is almost certainly also…

Yeah, I was not really trying to argue that that was actually the case, so won’t waste time trying to defend the merits of the model I pulled out of my arse.

Alternatively then, perhaps safety developments in cars made them safer to drive around the same time? Or maybe advances in medicine made fatal crashes less likely? Or perhaps there’s some other explanation that doesn’t immediately spring to mind, it’s irrelevant.

The only point I’m really making is that the data OP referred to does not show an increase in excess deaths, and in fact specifically fails to find this.

Post reply on HN