3 ms·

What reminds me of computer systems is how the spoilers partly compensated for the opposite role, the computer modes (direct vs. assisted) lead to different beh

by w10-1 4y ago

What reminds me of computer systems is how the spoilers partly compensated for the opposite role, the computer modes (direct vs. assisted) lead to different behaviors, the test display (green == good?) was mostly self-referential and did not indicate what they thought it should, etc. In short, the mental model required to understand the plane and its indicia of state was way too complex. These guys literally had to read technical manuals and follow (run-book) procedures step-by-step while the plane was cavorting. Dynamic stability is the tendency of a system to restore stability, given external forces. There should be a term for dynamic-breaking stability, the ability to restore stability when broken, while also maintaining dynamic and static stability. This is probably the only real benefit of devops: designing systems on the assumption people will need to intervene to fix them during moments of highest demand.

ilyt 4y ago
I watched a lot of accident videos and that kinda is the common trend. Many of them were caused not only by actual failure but by pilots not understanding what the plane was telling them, or plane sending mixed signals (whether actually or by pilot's misunderstandings) I remember one accident where part of the cause was that both pilots were trying to yank the plane in different direction, and the system just averaged out both inputs and as it was fly by wire and there was no feedback and "too much to do", pilots didn't notice. That's the reason why many planes have pilot's controls connected with eachother - so one can feel what the other one is trying to do. > This is probably the only real benefit of devops: designing systems on the assumption people will need to intervene to fix them during moments of highest demand. I have noticed the interesting trend when it comes to automating and "cattlefication" of everything - the less something breaks the less everyone involved understands it. Because it's automated and because nobody needs to even read anything to deploy it (just add a line in Puppet manifest and you're done) when it does break not even the author has a clue why. Documentation helps a little bit but there is a gulf between "describing what it is and how to use it" and "knowing enough to find where the problem is.
- Ma8ee 4y ago
  > Documentation helps a little bit but there is a gulf between "describing what it is and how to use it" and "knowing enough to find where the problem is. That is one of my pet peeves with modern development. A lot of things are way too easy to get started with, while very few people understands what is going on. And then when things doesn't work so well, there are even more tools and frameworks that can be deployed without understanding, but that in some ways mitigate the problems. But now it's even more complex, and suddenly there's a team of 20 people maintaining an application that doesn't do much more than moving some files between servers, reading them and saving records in a database. Sorry, not a database, five different types of databases that no one in any of the teams have any deeper understanding of.

by w10-1 4y ago

ilyt 4y ago

I watched a lot of accident videos and that kinda is the common trend. Many of them were caused not only by actual failure but by pilots not understanding what the plane was telling them, or plane sending mixed signals (whether actually or by pilot's misunderstandings) I remember one accident where part of the cause was that both pilots were trying to yank the plane in different direction, and the system just averaged out both inputs and as it was fly by wire and there was no feedback and "too much to do", pilots didn't notice. That's the reason why many planes have pilot's controls connected with eachother - so one can feel what the other one is trying to do. > This is probably the only real benefit of devops: designing systems on the assumption people will need to intervene to fix them during moments of highest demand. I have noticed the interesting trend when it comes to automating and "cattlefication" of everything - the less something breaks the less everyone involved understands it. Because it's automated and because nobody needs to even read anything to deploy it (just add a line in Puppet manifest and you're done) when it does break not even the author has a clue why. Documentation helps a little bit but there is a gulf between "describing what it is and how to use it" and "knowing enough to find where the problem is.

Ma8ee 4y ago
> Documentation helps a little bit but there is a gulf between "describing what it is and how to use it" and "knowing enough to find where the problem is. That is one of my pet peeves with modern development. A lot of things are way too easy to get started with, while very few people understands what is going on. And then when things doesn't work so well, there are even more tools and frameworks that can be deployed without understanding, but that in some ways mitigate the problems. But now it's even more complex, and suddenly there's a team of 20 people maintaining an application that doesn't do much more than moving some files between servers, reading them and saving records in a database. Sorry, not a database, five different types of databases that no one in any of the teams have any deeper understanding of.