7 ms·

Additive solutions are fundamentally easier than subtractive ones. If removing something, you run into the problem of chesterton's fence: if you don't complete

• iovrthoughtthis 6y ago
  and here we see why css is often write only.
  • KajMagnus 6y ago
    And why there are dedicated tools for finding unused CSS that can safely (hopefully) be removed without breaking anything https://www.google.com/search?q=find+unused+css https://www.google.com/search?q=find+unused+css
• sean_pedersen 6y ago
  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.
• gamegoblin 6y ago
  Your comment struck a chord with me from what I've seen in various enterprise codebases, and it also seems to have a flywheel effect. That is, it's possible for a small team of experts to keep a piece of software in a constant good, small state by always balancing additive vs subtractive solutions, because everyone has a fairly complete model of the entire project in their head. But if there is any tendency towards additive solutions (e.g. due to personnel churn, deadline crunch, etc), the project becomes larger and thus harder to keep a model in one's head. This makes subtractive solutions harder to think of and implement, which results in more additive solutions, thus exacerbating the problem.
  • spondyl 6y ago
    Given your comment, you'd probably really enjoy Peter Naur's "Programming as Theory Building" since it's effectively heading down a similar path of thought: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf The gist of it is that when a small team builds a piece of software, they have a theory (or I suppose a mental model by another name) of how it exists (either the literal files on disk or a rough abstraction of the "shape" it takes) and an understanding of the strengths and weaknesses of its design. One team may share the "theory" of the program with another by adding a new team member, they learn from osmosis (not just the codebase but the insights from other members). In reality, what often happens is that a team erodes through attrition or even is entirely removed from a project. The new team who takes over it, has no theory of how the software works and has to form an entirely new theory. That theory may be mismatched to the realities of the environment it lives in (infrastructure assumptions, cultural assumptions and so on) which can make additions even worse. I suppose I imagine it like the statue of David that gets created in Spongebob only for the weird, out of place squidward nose to be tacked on it like it works but it doesn't seem quite right and you can almost point out the line. Anyway, it's an interesting conundrum since there's not really an easy way to express this concept to big bloated corporations who think they can just exchange one contracting firm for another, and not end up with a mish mash hell contraption that shits all of their customers. The natural fix might feel like having sole indies running a project where the mental model is not in jeopardy (sans being hit by a bus) although I would think it's more in the range of 10 people or so but I honestly haven't gotten far enough to test that out yet :) Additionally, you could say that documenting not just the software itself, but the assumptions held at the time would work. It probably would help but that assumes future developers will read it (some will find a rewrite the only logical course because they don't understand the project, or the language etc) while others may just be under business pressure to "move as fast as possible" which gets mistaken for "writing code" instead of understanding what came before.
• bordercases 6y ago
  Counterpoint: adding locally is easier than subtracting locally, but subtracting globally is easier than adding globally. Blowing up a complex codebase to start again is an easier change than re-architecting the codebase through the investigation of its parts.
• inglor_cz 6y ago
  True. Try subtracting excessive salt from a meal that you are cooking.
• dvt 6y ago
  Your point holds even mathematically/logically. Consider addition vs subtraction. Living in a world where we're just adding, life is simple (1 + 5 + 32 + 67 + x + y + ...). But when we subtract, we're introduced to weird new concepts like zero and negative numbers. These new concepts require foundational shifts. This of course also applies to multiplication (constructive) vs division (destructive), where division introduces us to the weird concept of infinity when dividing by zero. And also exponentiation (constructive) and root-taking (destructive), where the latter introduces us to imaginary numbers when taking the root of negative numbers.
  • ktpsns 6y ago
    The mathematical analogy has its limits, thought. In analysis, integration (constructive) is analytically much harder then differentiation (destructive).
    • dvt 6y ago
      Good call-out, integration is a very strange beast.
    • marmaduke 6y ago
      Because integration reduces the dimensionality of the integrand, it is can be seen as subtractive in the sense above.
  • uvnq 6y ago
    The square root function is interesting, it seems to me to belong to some third class. Instead of constructing or destructing, it questions something's origin. For whatever reason, "origin questions" have an uncanny ability to yield really strange results.
    • dvt 6y ago
      Yeah, very true, technically log is the "opposite" of exp.
• anigbrowl 6y ago
  Theoretically, if there was unnecessary and harmful stuff in there, either someone would have complained and already gotten it removed Practically though, there are many contexts where people complain and are ignored. I think you're over-complicating it; the paper presents easy problems where Chesterton's fence would not be an issue, but upon observing the results they titled it 'People systematically overlook subtractive changes.'
  • antonvs 6y ago
    Looking at the lego structure in the article, it's pretty obvious that you could remove the "pillar support" and get a stable structure. But... without an explicit description of the goals of the structure, you don't know if there's some reason that the roof was supposed to be raised. An additive solution is less risky, essentially, and can be implemented in the face of incomplete knowledge. That's Chesterton's fence in a nutshell.
    • anigbrowl 6y ago
      Disagree. In this structure, a roof is supported by a pillar at one corner of a building. When a brick is placed on top, the roof will collapse onto the figurine. Adams et al. asked study participants to stabilize the structure so that it would support the brick above the figurine, and analysed the ways in which participants solved the problem. And in more detail from the notes on the original paper: Participants could stabilize the top platform of the Lego structure so it could hold a masonry brick above the head of the action figure by adding new supports to reinforce the single corner block or by removing the corner block and letting the platform sit flush on the layer below. They earned $1 for successful completion, but adding Lego bricks cost money. The most profitable solution was to remove the single support. Participants were randomly assigned to instructions that explicitly stated ‘removing pieces is free’ (cue condition) or instructions that did not mention removing pieces (control condition). It seems to me the problem to be solved was clearly stated (in the supplementary material, it is even more clear that the reference to a 'masonry brick' is an actual terracotta brick weighing ~3lbs, not an additional lego brick); the specific result was that In the control condition, 41% produced a subtractive transformation and in the subtraction-cue condition 61% produced a subtractive transformation; but a follow-up experiment involving reviews of possible solutions shows they were perceived as equally valid (also in the SM). I guess it's possible that what's being measured here is confused by a variable of whether people take things at face value, or assume 'there must be more to this even if not stated,' but even when told that removing bricks is acceptable, 40% of people choose not to.
• agumonkey 6y ago
  I think it can be solidly extended to any reverse concept. squaring ... easy. square roots: non trivial. or even in programming, with the symmetry of one way programming (imperative or functional) and relational (kanren). Oh ... I guess it may all boil down to bijective systems
• 6gvONxR4sf7o 6y ago
  I like the analogy, but the fair comparison would be comparing adding some specific piece versus subtracting some specific piece, or comparing adding some arbitrary piece versus subtracting some arbitrary piece. For the former, you have to check your potential addition against all pieces (N checks) or your potential subtraction against all other pieces (N-1 checks). For the latter, you check all potential additions against all pieces (K x N checks) or all potential subtractions against all other pieces (N x N checks). In your comment, you're comparing checking the viability of a known addition to the entire search for a viable subtraction, ignoring the search for a viable addition.
  • jjk166 6y ago
    really I'm just assuming K << N and constant as you can arbitrarily specify an addition but not a subtraction. Consider a nuclear power plant. While there might be an infinite number of potential safety valves I could add, it won't take me long to figure out one that will be good enough that I can safely add it somewhere without causing problems. Doubling the available valve options does not really make the task harder, but doubling the complexity does mean it takes about two times longer to validate it. On the other hand if we presuppose that there is one valve in the plant that should be removed, I will on average have to evaluate around half of all the valves before finding it. If you double the number of valves in the plant, now each evaluation is twice as hard, and I will on average have to do twice as many such evaluations, so the task should take about four times as long.
  • KajMagnus 6y ago
    Often (but not always), finding a good enough addition is "almost instant", O(1) — for example, in software, how to implement a new feature, can come to you directly, when you read the new feature description. But to find something to delete — then one needs to know about all existing source code — that takes O(N) to read and think about. (Unless keeps it all in memory) Meaning, in practice, it's often O(1 * N), versus O(N * N). But yes you're right about the cases when it's a complex thing that can be done in many ways.
• lmilcin 6y ago
  I think there is even more going on. - Adding is a repeatable, comfortable process whereas removing tends to require more individual approach. - Adding tends to be stressed a lot in corporate environment, whereas you don't hear your managers demanding to remove features. - Adding is usually easier to explain whereas explaining how removing functionality improves the system requires more effort on both sides. - Most people treat code as asset. Which is completely backwards way to think about it. I think about the code as liability. If your mental model of code as an equivalent of an asset, the most natural way to improve value of the system is to add more code to it. - Most techniques you read up on the Internet are aimed at adding brand new code, not at removing it.
  • ptidhomme 6y ago
    This is pretty much my experience. People tend to perceive every piece of code as valuable, however useless or stupid it may be, because of the time and money involved. Until the codebase gets so crippled that you hear the goto solution from these same people : complete rewrite.
    • lmilcin 6y ago
      Aaaaand that is another can of worms. I have recently had a potential client come to me to help them rewrite an old Java application. They have already been unsuccessful rewriting it once, now the want "somebody with more experience" to do this "the right way". So I ask them, "What is wrong with your old app?". Them: "Let's not focus on it, we are interested in how you plan the new one" Me: "No, really, I need to know what is the problem with the old app. Please, humor me." Them: "It is Java 1.6" Me: "Okay, but what is wrong with the app?" Them: "We need to upgrade to at least Java 11." Me: "And how about that app, what is wrong with it?" Them: "We are being chased by our security for at least past couple years. The problem with the app is that it uses old libraries that cannot be upgraded because of old Java. We tried to upgrade the Java but failed so we want to start with clean slate" Me: "But what is wrong with the app? I mean... if you have been unsuccessful upgrading Java that surely means there is some kind of underlying structural problem?" Them: "Yeah, we also have a lot of failed transactions but that is because of old libraries." Me: "Surely, you don't want to say that back when Java 1.6 was new it was not possible to write reliable applications?" Them: ... Me: "Also, why your previous rewrite failed?" Them: "That's simple, the developers were not up to the task." Me: "But who managed those developers?" Them: ... Me: "That's right. Last question, how did you decide to rewrite the application if you don't know what is the problem with the previous one?" Them: "What do you mean?" Me: "No, thank you, I learned everything I needed. Goodbye"
• mycall 6y ago
  As you are right with the general simplicity of additive solutions, it is in differential maths where many great insights have come from. * Infinitesimal differences or to the derivatives of functions in calculus, differential geometry, algebraic geometry and algebraic topology. * General relativity with it's underlying differential geometry and differential topology for manifolds, pullbacks and covariant derivatives or differentials of vector fields and tensor fields * Difference in differences between treatment group versus a control group I couldn't imagine what our understanding of the world would be like without subtractive solutions.
• mhb 6y ago
  I like this description, but one thing bothers me about the last part with multiple people. The end product is acceptable to everyone since they might have had a chance to veto some aspect and didn't. When adding a new piece, you would need to consider whether it would have been unacceptable to any of the people. That doesn't necessarily seem easier than taking something out.
  • jjk166 6y ago
    If you add something, you need to convince N people that it's acceptable. To remove something, you must convince N people not only that it is acceptable, but that it is preferable to removing any of the other options. It may be easy to convince most people that a farm subsidy is doing more harm than good, but it's hard to convince the farmers that there aren't any other subsidies that could be cut instead.
    • mhb 6y ago
      Your example creates an asymmetry where there isn't necessarily one. To make the situations comparable, if you're adding something, you should have to convince the N people that there are no better things to add. The same as your suggestion that they would need to accept that the removal of a particular thing is preferable to all other possible things that could be removed. In fact, it seems easier to remove something since there are only the things that people have already agreed on. To add something it could be compared to a world of possibilities which might be better.