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

Suppose I wanted to kill a lot of pilots

historyofyesterday.com

Post reply on HN
Print view View original

161–170 of 178 posts

Re: Suppose I wanted to kill a lot of pilots

#161

Post by lamontcg »

themodelplumber wrote: post #109
lamontcg wrote: post #107

I do this all the time. At work, I'd consider what it would take to wipe all the servers, and all the backups (while creating enough of a distraction on the network to delay people from pulling the power in the datacenters). We had way too many people with global root access that could have done something about it, so the point would be to consider engineering to restrict access (this was before kubertnetes took over…

> Probably good that not everyone in the world thinks the way I do. It's funny because HN (in contrast to the world at large) seems to be frequented by a lot of people who are gifted with the forward-looking contingency mindset. I'll bet that's why you got upvoted, and it's probably why the article was posted. One reason why a community like this would exist online is because it's effectively a saf...err I mean frien…

I think the fear response comes from people who don't assign probabilities to things, so they just see that everything is a risk (leading to disorders like OCD in the extreme).

And at work you can see people focusing on mitigating the wrong security issues. There's a sort of maslow's heirarchy of security that needs to happen, and some people noodle way too hard on memory bit flipping attacks and not on just making sure you can't ssh into something with a guessable root password. Of course its more intellectually challenging to think about all the ways that the NSA could break into Google, but if you don't work at Google its all the boring shit you need to make sure you have in order.

Re: Suppose I wanted to kill a lot of pilots

#163

Post by yinzer-solomon »

jacquesm wrote: post #45
ethbr0 wrote: post #42

I first heard about this in the context of software project estimation. The author (forgotten to me) made the point that nobody has permission to think about disasters when estimating project completion time. So why not explicitly ask them to? "So now we have our estimate, what would cause us to miss it?" And in the course of giant monster attacks, you give people permission to talk about specific scenarios that are…

Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.

As Goldratt says in “Beyond the Goal”: Any project management methodology that doesn’t account for Murphy’s Law is not a realistic methodology.

Re: Suppose I wanted to kill a lot of pilots

#165

Post by stanrivers »

kolinko wrote: post #61
dTal wrote: post #59

> rather than solving for success, solve for failure. If you want to design a dust filter that works at 600 Celsius within a steel mill, instead design all the ways you could develop a filter that would fail miserably in those conditions. That's a strange example. There are infinite ways of not accomplishing a task, and as a non-expert in filter design I have no trouble listing them: make the filter out of butter, ma…

The point is to make a filter that works in lower temperatures but breaks around 600C. Using the other example - of course to kill the most pilots you coukd out them in a big meat grinder or just blow up their planes. But the point is to design planes so that they both fly and kill pilots.

Hahaha I love this response; yes, you can always change the rules of the game, so to speak, and make things worse; however, if you keep within the rules of reality then it might be a bit more useful.

Re: Suppose I wanted to kill a lot of pilots

#166

Post by AussieWog93 »

kortex wrote: post #149
AussieWog93 wrote: post #77

Earlier quoted context omitted.

>What if I wanted to make a program as slow and bloated as possible? >put all state in one place. >no caching. Just as a counterpoint, both as a user and a developer I've found the main cause of performance issues and UI bugs come from a combination of distributed state and caching. State being stored as a private member on the widget object itself is arguably more likely to cause a state desync bug or accidental O(N…

> Just as a counterpoint, both as a user and a developer I've found the main cause of performance issues and UI bugs come from a combination of distributed state and caching. Isn't that like, the main cause of most software headaches? insert joke about cache invalidation and naming things . It sounds like you're saying bad caching can be worse than no caching. I can absolutely see that being the case. > - Make it dif…

>It sounds like you're saying bad caching can be worse than no caching. I can absolutely see that being the case.

More specifically, I'm saying that caches (implicit or explicit) can and do go wrong, and the simplest way to avoid invalidation errors (and the performance hiccups when higher-level developers start manually invalidating the cache to work around them) is to just implement them in as few places as possible.

Re: Suppose I wanted to kill a lot of pilots

#167

Post by djmips »

jedberg wrote: post #117

I've been doing this my entire working career. I didn't realize it wasn't something everyone does! When I worked in security, the first question I always asked was, "how would I defeat this system". When I worked in reliability, my first question was always, "how can I break this?". And now that I'm founder, I ask myself, "how will my business fail". I know that the executives at a lot of large public companies have…

Yeah, I think this way by default. It really does seem a natural for security!

Re: Suppose I wanted to kill a lot of pilots

#168

Post by underwater »

oceanghost wrote: post #80
jacquesm wrote: post #45

Earlier quoted context omitted.

Spot on. They used to call me 'Dr. No' because that is exactly what I would do, but it saved us tons of money so it was tolerated. We also actually delivered on time and within the budget but I'm sure it cost us contracts to more optimistic competitors.

This. Most engineers delude themselves and plan for the happy path. I was famous too for "being negative." In the planning of a complex project once a rather dull engineer, after I had just pointed out a major potential problem asked, "Why are you so negative?" "I'm not negative, I'm planning for success."

I've seen a lot of engineers be negative in a destructive way. They tear down ideas, but fail to offer solutions. Usually this is about their ego rather than a desire to help the team.

Re: Suppose I wanted to kill a lot of pilots

#169

Post by samatman »

DangitBobby wrote: post #91
markmsmith wrote: post #34

Before I do anything, I ask myself: 'Would an idiot do that?' And, if the answer is yes, I do not do that thing. - Dwight Schrute

"Would an idiot eat breakfast?" Uh oh.

Jokes on you I do intermittent fasting, only coffee until noon.

Re: Suppose I wanted to kill a lot of pilots

#170

Post by catherd »

nohuck13 wrote: post #138
bumby wrote: post #134

Earlier quoted context omitted.

It can depend on accountability mechanisms. I would like to see more contracts that give bonuses to companies that come in under budget and under schedule and penalize the overly optimistic ones that never seem to hit their target. This is becoming more common in some domains.

What domains is it becoming more common in, in your experience?

My contract manufacturing company does this. Our standard contract has a 5% bonus for being less than 10% late on the delivery date (and penalties start around 25% late). After suppliers see the contract they will often revise their originally quoted schedule.
Post reply on HN