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

Re: Suppose I wanted to kill a lot of pilots

#51

Post by fastball » Sat, Jul 03, 2021, 1:40 PM UTC

golergka wrote: post #31

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.

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

Re: Suppose I wanted to kill a lot of pilots

#52

Post by amelius » Sat, Jul 03, 2021, 1:40 PM UTC

MattGaiser wrote: post #37

WesolyKubeczek wrote: post #27

Earlier quoted context omitted.

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

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

Yeah, minimalism is great to reduce dirt/dust collection points.

By the way, I think toilets which are attached to the wall instead of to the floor are great because you can easily mop under them.

Re: Suppose I wanted to kill a lot of pilots

#53

Post by tjchear » Sat, Jul 03, 2021, 1:43 PM UTC

Is there a software invention/systems equivalent of TRIZ matrix?

Some of the dimensions/parameters we wish to analyze that I can think of may include:

  - latency  
  - throughput  
  - modifiability  
  - binary/data size  
  - memory size  
  - cpu cycles  
  - interoperability/compatibility  
  - accuracy  
  - precision  
  - staleness  
  - bandwidth
  - availability
  - etc

As a simple example, perhaps we want to reduce bandwidth while preserving data size. One of the resolutions may include compression (lossless/lossy).

Re: Suppose I wanted to kill a lot of pilots

#54

Post by 0xF57A » Sat, Jul 03, 2021, 1:49 PM UTC

>Continue to be a rent-taker as opposed to adding value

One of the most pervasive falsehoods in existence. Take them out of the equation and play the scenario through. What do you end up with?

Re: Suppose I wanted to kill a lot of pilots

#55

Post by mannykannot » Sat, Jul 03, 2021, 1:55 PM UTC

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…

Proactive pessimism.

Re: Suppose I wanted to kill a lot of pilots

#56

Post by mananaysiempre » Sat, Jul 03, 2021, 1:58 PM UTC

sam_lowry_ wrote: post #26

The basic premise of TIPS was that one could train engineers on solving problems, pretty much like martial arts trainers do: by exercising and learning tricks. Theory of Inventive Problem Solving nicely abbreviates as TIPS. That's how it has been known in the west for decades. ТРИЗ is a Russian acronym. TRIZ just replaces Cyrillic letters with equivalents. If the author digged a bit deeper, they would have known it a…

For what it’s worth, theory of inventive problem solving is not a very good translation of теория решения изобретательских задач teorija rešenija izobretatelʹskih zadač: as far as I can see, it parses as [inventive [problem solving]] with inventive meaning something like “unconstrained by convention, prolific intellectually, embodying the spirit of invention”, for which the proper Russian is изобретательный izobretat-elʹ-n|yj; the original name has a different syntactic structure and uses изобретательский izobretat-elʹ-sk|ij “belonging to or characteristic of inventors”, so the proper translation would instead be something like theory of solving problems of invention, which is admittedly awkward (and doesn’t afford a snappy acronym) but at least successfully conveys the idea that the “invention” part pertains to the problems, not the solutions or the theory.

Re: Suppose I wanted to kill a lot of pilots

#57

Post by the__alchemist » Sat, Jul 03, 2021, 1:59 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 -…

Your FP example reminds me of the JS trend that picked up about 5 years ago. Not sure if they're still doing it, but you described the dogma near perfectly.

Re: Suppose I wanted to kill a lot of pilots

#58

Post by chasebank » Sat, Jul 03, 2021, 2: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?

Not really but kind of. An algorithm we developed to trade futures was so terrible, we inverted it and it became the base of our most profitable strategy.

Re: Suppose I wanted to kill a lot of pilots

#59

Post by dTal » Sat, Jul 03, 2021, 2:03 PM UTC

> 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, make it just a big hole, pay someone to pluck dust out of the air with tweezers... how exactly is this helping?

Re: Suppose I wanted to kill a lot of pilots

#60

Post by brightball » Sat, Jul 03, 2021, 2:06 PM UTC

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…

PI Planning in SAFe explicitly calls for this. Risks to the plan are called out in front of everyone and each is discussed to see if it can be mitigated (and who will own that mitigation).

If anything happens due to one of those foreseen issues, everybody knew about it in advance and already discussed what, if anything, could have been done to prevent it as well as what action was actually taken.

I love the SAFe / PI Planning approach because it makes sure that everybody is on the same page and totally removes any blame game from deliverables. Far, far fewer surprises.