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

101–110 of 178 posts

Re: Suppose I wanted to kill a lot of pilots

#101

Post by corobo »

alisonkisk wrote: post #74
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…

The reason no one does this is because thr answer is constant "something might fail and add an arbitrary delay" once you hace committed to play the estimation game, you're committed to the delusion and reality checks dont matter. Just stop trying to estimate.

"just" is thrown around far too much on this site

I'm sure my boss and customers will appreciate me saying "it takes as long as it takes", nothing will go wrong, it's clearly just that simple :)

Why not instead of working at all just earn a million a year off the interest from a well performing stock portfolio instead?

Re: Suppose I wanted to kill a lot of pilots

#102

Post by ethbr0 »

13of40 wrote: post #92
tonyedgecombe wrote: post #47

Earlier quoted context omitted.

You need a distinct pre-mortem where everybody brings a list of the ways a project could fail. https://en.wikipedia.org/wiki/Pre-mortem

I just deployed something worldwide that took about six weeks to develop and our initial guess was about two weeks, so this is fresh in my mind. I was able to lay out a list of work items at the beginning that stayed like 80% the same from the beginning to the end, but didn't account for the possibility that each one of these could be push-button, or could lead to a blocking problem that needed a day or two of resear…

The best framing I've heard for this problem is: minimum time for each component is bounded, maximum time is unbounded. I.e. there is effectively no answer to the question "If this component becomes a problem, what is the maximum amount of time it could take to solve it with the resources available?"

Ergo, in the worst case, any given single component's ballooning time can dominate the overall project schedule.

Which turns estimation into a game of "How certain am I that no component's time will explode?" To which the answer in any sufficiently complex system is "Not very."

I'm pushing my work to move to something more like a converging uncertainty plot, as milestones are achieved and we can definitely say "This specific component did not explode."

Our PMs aren't used to hearing an idealized minimum schedule time + an ever decreasing uncertainty percentage based on project progress, but it feels like less of a lie than lines in the sand based on guesses.

(Note: This is for legacy integration development, which probably has more uncertainties than other dev)

Re: Suppose I wanted to kill a lot of pilots

#103

Post by [deleted] »

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

[deleted]

Re: Suppose I wanted to kill a lot of pilots

#105

Post by olvy0 »

fastball wrote: post #51
golergka wrote: post #31

Earlier quoted context omitted.

> What if I wanted to make a program as slow and bloated as possible? That sounds like a very exact description of React/Redux.

We've built a React/Redux application[1] that people keep telling us is very snappy, and we definitely haven't optimized as much as is possible, so from my experience React/Redux is not inherently slow and bloated. [1] https://my.supernotes.app

FWIW it takes 7-8 seconds to load on my computer as well, on the latest Firefox, with a good CPU.

This has finally convinced me to not waste my time learning React, at least for now.

Re: Suppose I wanted to kill a lot of pilots

#106

Post by pjmlp »

bayesian_horse wrote: post #86
pjmlp wrote: post #76

Earlier quoted context omitted.

Thé irony being that JavaScript doesn't add anything that Smalltalk didn't already provide, yet we have all this OOP backslash and how FP is somehow better.

Well, Javascript is the language that is able to run everywhere, so that's what frontend engineers have to target. There is some more flexibility now with Webassembly... If you are interested, look up Fable, Bolero, Elm, PureScript, ClojureScript, Grain...

All of them don't wash away JavaScript semantics, just because the source language is something else.

Re: Suppose I wanted to kill a lot of pilots

#107

Post by lamontcg »

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 the world).

Walking down the street yesterday I saw someone had a little bucket full of dog treats for anyone to take and my first thought was the risk of someone spraying a bit of poison on them. I don't necessary "fear" things like that, but its just obvious to me that you're implicitly trusting the thousands of people who has walked past that box not to be pathological.

Probably good that not everyone in the world thinks the way I do.

Re: Suppose I wanted to kill a lot of pilots

#108

Post by LorenPechtel »

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…

It's an occupational hazard for us computer guys. It's the failure mode you didn't think of that brings the system down, so of course you learn to think of the failure modes.

Re: Suppose I wanted to kill a lot of pilots

#109

Post by themodelplumber »

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 friendly place for people who are concerned about future events, but in a positive, problem-solving sort of way. The rest of the world doesn't always reward this or want to hear about it.

IT, operations, and even software development need people who can think this way (particularly the opportunistic side of software dev, as it is more COTS-components oriented and thus less NIH and thus theoretically more battle-tested/hardened against future events).

Sadly one of the things I've noticed about those with this mindset is that if they are not able to act on their perceptions constructively, for example if they were raised in an environment where it was considered a crazy way to think about things (focus only on past or present), it can turn into a more subjective, fear-based practice. In those cases it seems you get more outcomes like a stance where even just going outside feels to a person more like gambling with their life. Just observationally speaking...

Post reply on HN