9 ms·

I don't get how the additive solution does not require to understand the whole system and all it's interactions. If I place a jenga block I need to understand t

I don't get how the additive solution does not require to understand the whole system and all it's interactions. If I place a jenga block I need to understand the static properties of the whole jenga tower to prevent collapse.

deleted 6y ago
[deleted]
jerf 6y ago
You can, by construction, create an additive solution that interacts with only your choice of bits of the previous system. To remove, you must be sure you know the full interaction graph it already has. I encounter this in code all the time. I'm currently dealing with a support case where I tried to remove ~10 lines of code, and wouldn't you know it, it's causing issues. By contrast I add lines of code by the hundreds all the time with virtually no issues. Jenga's only a metaphor, don't too caught up in it. Most human-designed systems don't have dependency graphs that look like that. Ugly ones, sure, ones that don't match the pretty diagrams, sure, but we don't generally build systems where literally everything critically depends on everything else, if for no other reason than we aren't good enough to build that sort of system without it coming down around our ears almost immediately. We have to have some degree of isolation. https://xkcd.com/2347/ https://xkcd.com/2347/ (There are multiple places where for simplicity I'm not adding caveats, like, obviously I can't always add 100s of lines with no issues.)
deleted 6y ago
[deleted]
teachingassist 6y ago
A Jenga turn requires you to remove a block from the tower, and then add the same block to the top of the tower. You seem to be claiming that you believe these two actions (subtracting and adding) are theoretically of equal difficulty - but in practice, they are not equally difficult. It's far more common, almost to the point of certainty, that you will lose by removing an existing block. You are vastly more constrained in your actions when removing blocks that are already placed.
- Twisol 6y ago
  Removing a piece is scarier, because it feels so delicate, but you get plenty of tactile feedback from the piece you're pulling that tells you whether you're doing a dumb and should switch pieces. If there are no viable pieces, you're probably going to lose. Adding a piece has no feedback. If you slightly nudge the tower while placing the piece, it could very easily topple then and there. You have to judge where to place the piece, and commit to it, without any room to finesse the placement if something goes wrong. Anecdotally, all my Jenga losses have been when I was too stubborn with a pull, or when I simply misjudged a placement. Beyond the immediate analogy, I don't think Jenga really matches with software development. In Jenga, the material you have to work with is fixed, and you must always move material rather than truly adding or removing over time. (And a Jenga game is designed to end in failure, unlike (or is it?) software engineering.) If you look at something like a sand pile, where you're always adding grains, you'll find irregular but predictable catastrophes as the structure fails.
jjk166 6y ago
Additively, you need to know how your 1 addition interacts with all n elements of the existing system, so there are n things you need to understand. Subtractive, you need to do that same analysis for every part of the system you could potentially remove, so you're doing n operations n times each. The subtractive analysis only becomes equivalent to the additive one if you know a priori which specific element you ought to remove. Placing a jenga block, you can choose to put it in a location that is relatively easy to analyze, for example the middle of the next layer up. Removing a jenga block, you first need to decide on which block to remove, and then you have to deal with the situation it actually happens to be in. Either action could knock the tower over, but the odds of you getting something wrong go up dramatically during the removal phase.

deleted 6y ago

[deleted]

jerf 6y ago

You can, by construction, create an additive solution that interacts with only your choice of bits of the previous system. To remove, you must be sure you know the full interaction graph it already has. I encounter this in code all the time. I'm currently dealing with a support case where I tried to remove ~10 lines of code, and wouldn't you know it, it's causing issues. By contrast I add lines of code by the hundreds all the time with virtually no issues. Jenga's only a metaphor, don't too caught up in it. Most human-designed systems don't have dependency graphs that look like that. Ugly ones, sure, ones that don't match the pretty diagrams, sure, but we don't generally build systems where literally everything critically depends on everything else, if for no other reason than we aren't good enough to build that sort of system without it coming down around our ears almost immediately. We have to have some degree of isolation. https://xkcd.com/2347/ https://xkcd.com/2347/ (There are multiple places where for simplicity I'm not adding caveats, like, obviously I can't always add 100s of lines with no issues.)

deleted 6y ago

[deleted]

teachingassist 6y ago

A Jenga turn requires you to remove a block from the tower, and then add the same block to the top of the tower. You seem to be claiming that you believe these two actions (subtracting and adding) are theoretically of equal difficulty - but in practice, they are not equally difficult. It's far more common, almost to the point of certainty, that you will lose by removing an existing block. You are vastly more constrained in your actions when removing blocks that are already placed.

Twisol 6y ago
Removing a piece is scarier, because it feels so delicate, but you get plenty of tactile feedback from the piece you're pulling that tells you whether you're doing a dumb and should switch pieces. If there are no viable pieces, you're probably going to lose. Adding a piece has no feedback. If you slightly nudge the tower while placing the piece, it could very easily topple then and there. You have to judge where to place the piece, and commit to it, without any room to finesse the placement if something goes wrong. Anecdotally, all my Jenga losses have been when I was too stubborn with a pull, or when I simply misjudged a placement. Beyond the immediate analogy, I don't think Jenga really matches with software development. In Jenga, the material you have to work with is fixed, and you must always move material rather than truly adding or removing over time. (And a Jenga game is designed to end in failure, unlike (or is it?) software engineering.) If you look at something like a sand pile, where you're always adding grains, you'll find irregular but predictable catastrophes as the structure fails.

jjk166 6y ago

Additively, you need to know how your 1 addition interacts with all n elements of the existing system, so there are n things you need to understand. Subtractive, you need to do that same analysis for every part of the system you could potentially remove, so you're doing n operations n times each. The subtractive analysis only becomes equivalent to the additive one if you know a priori which specific element you ought to remove. Placing a jenga block, you can choose to put it in a location that is relatively easy to analyze, for example the middle of the next layer up. Removing a jenga block, you first need to decide on which block to remove, and then you have to deal with the situation it actually happens to be in. Either action could knock the tower over, but the odds of you getting something wrong go up dramatically during the removal phase.