Suppose I wanted to kill a lot of pilots • Hacker News Board

Re: Suppose I wanted to kill a lot of pilots

#31

Post by golergka » Sat, Jul 03, 2021, 12:46 PM UTC

kortex wrote: post #25

Suppose I wanted to make a program inscrutable, hard to modify, hard to test, heavily coupled, and hard to reason about: - hide information so that it's not queryable - force information to flow through multiple hops - make it hard/impossible to set the true state of the system in its entirety - allow state to be mutated silently - give interfaces roles and force certain state to have to flow through specific paths -…

> What if I wanted to make a program as slow and bloated as possible?

That sounds like a very exact description of React/Redux.

Re: Suppose I wanted to kill a lot of pilots

#32

Post by chrismorgan » Sat, Jul 03, 2021, 12:51 PM UTC

kaycebasques wrote: post #11

HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?

Testing is a good example of a field that is ineffective if you don’t adopt this sort of adversarial approach. When I’m writing unit tests for something, as well as having some regular test cases of expected inputs and outputs, I’m always trying to find ways of breaking the code under test. This regularly surfaces problems that might otherwise have been overlooked and caused trouble (most commonly logic errors that can be a nightmare to diagnose if you don’t have a time-travelling debugger) later on.

Re: Suppose I wanted to kill a lot of pilots

#33

Post by iandanforth » Sat, Jul 03, 2021, 12:55 PM UTC

codetrotter wrote: post #18

kaycebasques wrote: post #11

HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?

On a small scale I find this way of thinking useful in software development. Say that you are implementing a role-based access control system. And then ask yourself how can my RBAC system fail? Well one way it could fail is if someone without the necessary role can operate on something that they ought not have access to. So then create roles A, B, and C, and create a resource and say that group A can rw, and group B…

I'm not sure "negative test cases" and "thinking about the problem in reverse" are the same thing.

Thinking about larger systems is much more amenable to this approach. Taking your example if we extend RBAC to an auth/authz service we can say the following.

I want my service to be unreliable. In what ways?

I want it to be occasionally inaccessible or non-responsive, produce results that are non-deterministic and inaccurate.

Taking one of those, how would I produce non-deterministic results? I'd make every operation tied to a PRNG, or be a function of something external to the system I don't have control over. Or maybe it could look non-deterministic if I make my logic dependent on time.

How would flesh out an unreliable function based on time?

I'd offer functionality proposed to tie RBAC to the local clock of the user. This way I'd have to deal with timezones, differences in user localities, relativity, leap years/seconds etc. Functions built on that would likely give the impression of being non-deterministic across many users. (Even assuming correct implementation).

Ok what about being inaccessible vs non-responsive?

The easiest thing to do is just shut the system down of course to maximize this objective, but we want the worst possible system so that's one that may or may not be there and may or may not respond. I could set up my load balancer to include nodes that don't exist, I could run jobs on the service boxes at regular intervals that consumed 100% CPU preventing their responses. I could ...

...

And you can go on and on trying to find all the design and config choices that would make for a truly maddening service. Then you say OK from the product feature level down how can I avoid doing any of those things.

Re: Suppose I wanted to kill a lot of pilots

#34

Post by markmsmith » Sat, Jul 03, 2021, 12:55 PM UTC

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

Re: Suppose I wanted to kill a lot of pilots

#35

Post by atatatat » Sat, Jul 03, 2021, 12:56 PM UTC

spydum wrote: post #30

Sounds a lot like threat modelling. It's great, if you are creative enough to imagine all the threat scenarios.

Or at minimum, the likely ones.

Re: Suppose I wanted to kill a lot of pilots

#36

Post by mherdeg » Sat, Jul 03, 2021, 1:00 PM UTC

I've worked with engineers who have used a premortem -- once they have the bare sketch of a project to solve a problem, they imagine that it failed and think about the most likely causes, then adjust their project to mitigate those risks.

The process described here happens a step earlier, when you're deciding which projects to tackle in the first place, which is an interesting angle.

Re: Suppose I wanted to kill a lot of pilots

#37

Post by MattGaiser » Sat, Jul 03, 2021, 1:00 PM UTC

WesolyKubeczek wrote: post #27

MattGaiser wrote: post #23

Earlier quoted context omitted.

Maybe not quite the same thing, but I recently won an innovation challenge for improving public bathrooms. I started with what actions people take that make the bathroom as disgusting (pee everywhere, vomit, shoving food in the walls, etc) and then determining defensive mechanisms from there.

Could you please share more about what you have actually come up with?

https://d18qs7yq39787j.cloudfront.net/uploads/solutionfile/6...

Re: Suppose I wanted to kill a lot of pilots

#38

Post by jbluepolarbear » Sat, Jul 03, 2021, 1:01 PM UTC

kaycebasques wrote: post #11

HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?

Constantly, as the article states, some problems can’t be solved. But they can be incrementally made less problematic. I’ll use game networking as an example: there is no one way to solve networking between clients and servers. There is however a lot of ways to ruin the networking. So think about it it reverse. If I want the client to have a very poor experience I’d put them on an unstable network (cell), I’d have random packets dropped, I’d send at a rate higher than the clients download speed. Turns out these are really common problems with many options for addressing.

I think of it less of reverse the problem and more changing my frame of reference or perspective of the problem.

Re: Suppose I wanted to kill a lot of pilots

#39

Post by palijer » Sat, Jul 03, 2021, 1:01 PM UTC

kaycebasques wrote: post #11

HN loves this idea of thinking in reverse. Is anyone here actually doing it? What problem did you solve?

I'm in QA, and this is something like what I've been doing with running pre-mortems.

Basically, at the project planning stage, I get everyone together and ask how this shit is going to blown up in our faces. What are all the scenarios that are complete failures.

Then a few weeks before a release, I do the same thing. It's amazing the issues this catches from the cross team approach. For instance, something that the product manager was worried about, they never brought up because they assumed engineering knew about it was covered, but in reality, they had no idea that was important.

Or with two engineering teams, or DevOps etc. Normally we have more than a dozen action items out of these meetings.

Re: Suppose I wanted to kill a lot of pilots

#40

Post by GuB-42 » Sat, Jul 03, 2021, 1:03 PM UTC

lordnacho wrote: post #4

Suppose I want to build a program that trades in the markets to make money. So to do the opposite I would try to lose money as fast as I could, according to this? But the way to do that is just to churn my book a lot and pay costs and spreads. It's not clear how that illuminates how to make money.

It actually illuminates more than you might think. The market is mostly a zero sum game. When someone loses money, someone makes money, and vice versa.

Just think about it. I think the best way to lose a lot of money is to fall into scams. And avoiding scams is an important part of investing. It also tell you that scams can be profitable. So the next question is: how to scam and lose money doing it, which will hopefully put you back on the right track... or make you a really good scammer. Back to honest investing, losing a lot of money is not that trivial. It is easy to take risks but you can still get the occasional big payoff and if you think about ways of not getting that payoff, it is the same as thinking about how to get it, just with a different angle.

That kind of reverse thinking goes best when you pair it with regular thinking. That's a "meet in the middle" algorithm, kind of like solving a maze by going both forwards from the entrance and backwards from the exit.