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

Preparedness Paradox

en.wikipedia.org

Post reply on HN
Print view View original

61–70 of 130 posts

Re: Preparedness Paradox

#61

Post by robocat »

Trasmatta wrote: post #38

I’m having this struggle with projects at work. I’ve had to push back on all sorts of requests from our project manager and designer so that our team has the bandwidth to focus on some very important stability and security concerns for our next release. They want all sorts of additional fancy bells and whistles (that don’t add much user value or functionality) that we just can’t focus on right now, because it would c…

Hero’s get rewarded: allow something critical to break in a non-catastrophic manner and then get recognition for fixing it promptly (ideally with some high profile drama).

There is usually far less reward for preventative measures that avoided breakage in the first place.

Re: Preparedness Paradox

#64

Post by bee_rider »

omnicognate wrote: post #37
bee_rider wrote: post #30

Earlier quoted context omitted.

Yeah, this is something that has always bugged be a tiny bit. I was more familiar with the idea of a paradox as something like your definition -- containing an actual contradiction. But it seems to be used instead to describe any initially counterintuitive situation. It is tempting to attribute this to a technical/non-technical difference (similar to fallacy, which in non-technical discussion has been expanded to bas…

Paradox isn't synonymous with contradiction. Some paradoxes are, or contain, logical contradictions (i.e. they effectively say both X and not X are true) but the term is much broader. Some of the earliest paradoxes are Zeno's, and they were referred to by that term at the time. For example the paradox that an object that moves towards a point must first cover half the distance, and then half the remaining distance, t…

That's fair, the thing I'm looking for isn't quite a contradiction.

What I like about Zeno's motion based paradoxes is they have this aspect of "here's a reasonable model of motion, and here's the ridiculous result you get from it." There's clearly something wrong in the model, but working it out takes a while, you need someone to come around and invent series first.

After a little reading, I think I just like falsidical paradoxes and don't like veridical paradoxes.

Re: Preparedness Paradox

#65

Post by bee_rider »

vapemaster wrote: post #59
bee_rider wrote: post #30

Earlier quoted context omitted.

Yeah, this is something that has always bugged be a tiny bit. I was more familiar with the idea of a paradox as something like your definition -- containing an actual contradiction. But it seems to be used instead to describe any initially counterintuitive situation. It is tempting to attribute this to a technical/non-technical difference (similar to fallacy, which in non-technical discussion has been expanded to bas…

i always heard it called the birthday problem: https://en.wikipedia.org/wiki/Birthday_problem [weirdly, someone discovered an birthday overlap today at work and i just re-google/wiki'd this today]

Huh, what are the odds that the same mathematical concept will come up in conversation twice on one day? We have invented the Synchronicity paradox, er, problem.

Re: Preparedness Paradox

#66

Post by aaron695 »

_ea1k wrote: post #11
aaron695 wrote: post #2

Incoherent. How can there be a levee paradox. You can see the water it holds back. More people build because there are less floods. No idea what they are talking about with Fukushima The Millennial Bug is a good prospect. But that's a debate in itself.

Good point about the levee issue. Apparently there's a little wikiwar going on with that one already. I couldn't follow their logic with Fukushima either. The wording was a little strange. The Year 2000 scenario and covid scenarios are great examples IMO. The problem is that any great example is intrinsically going to be controversial, and that seems to be the paradox itself.

No post body was provided.

Re: Preparedness Paradox

#67

Post by wefarrell »

Trasmatta wrote: post #38

I’m having this struggle with projects at work. I’ve had to push back on all sorts of requests from our project manager and designer so that our team has the bandwidth to focus on some very important stability and security concerns for our next release. They want all sorts of additional fancy bells and whistles (that don’t add much user value or functionality) that we just can’t focus on right now, because it would c…

Yet if you acquiesced to those bells and whistles and there were stability or security problems it would be much worse for you personally.

It sounds like you guys don't trust each other - they don't trust your ability to assess risk and you don't trust their ability to properly value features vs those risks. As a tech lead in those environments sometimes it helps to act like a lawyer, communicate the risks, let them make the decisions but cover your ass and get everything in writing.

Re: Preparedness Paradox

#68

Post by a_e_k »

So that's why no one will buy my tiger-repelling rock!

(It's so effective at keeping the tigers away that no one around here is concerned about tigers.)

Re: Preparedness Paradox

#69

Post by quickthrower2 »

anonporridge wrote: post #40
huetius wrote: post #8

Not doubting this, but it seems to cut both ways. I can just as easily justify an overreaction by claiming to have averted some worse outcome. It seems to be a general problem of counterfactuals.

This is why it's often good resource management to wait until something breaks before committing resources to fix it. Especially true in software systems. One might think that constant firefighting is a waste of resources, and we'd be better off solving problems before they happen. That's true if and only if you know for sure that the problem and eventual breakage is really going to happen AND that it's worth fixing.…

This is why I think most of the 'absolutes' that programmers, software architects, managers etc. talk about are not so.

For example you must never declare 'magic numbers' in code. Or you must always obey S.O.L.I.D. or get 100% TDD. There will be be people who believe in these dogmatically to the point they won't employ anyone who says different (it becomes an interview question).

I am not arguing that these are wrong!

I am arguing that they are not evidence driven (they cannot be, software is to complex, it is not a narrow experiment on a lab mouse). So they must be culture/preference/worldview driven.

When there is no evidence driven approach to 99% of your decisions on software it becomes: an art. And that is fine.

That said it might be possible to show evidence that an approach is good for your code base, for your team, as that is a more limited scope, rather than "in general".

What isn't fine is the number of overly confident global assertions we hear from software people about how to build software.

Re: Preparedness Paradox

#70

Post by makeitdouble »

anonporridge wrote: post #40
huetius wrote: post #8

Not doubting this, but it seems to cut both ways. I can just as easily justify an overreaction by claiming to have averted some worse outcome. It seems to be a general problem of counterfactuals.

This is why it's often good resource management to wait until something breaks before committing resources to fix it. Especially true in software systems. One might think that constant firefighting is a waste of resources, and we'd be better off solving problems before they happen. That's true if and only if you know for sure that the problem and eventual breakage is really going to happen AND that it's worth fixing.…

This is the no-brainer choice for anything that can be immediately replaced/ordered. Most of us aren’t keeping a stash of computer monitors in case of failure.

On firefighting…huge swaths of burned down land can’t be reordered on Amazon and delivered next day. People quip “just replant the trees” but of course that doesn’t rebuild an ecosystem, we might not even replant the right trees, and the things that lived there are now dead.

On personal scales, waiting for your car to break to fix it isn’t a good strategy either, nor would you wait for you gas pipes to leak, or see if the thunder actually hits your home before preparing for it.

Basically I feel “don‘t fix until it breaks” is a good strategy for day to day small scale decisions, but problematic for most stuff beyond that.

Post reply on HN