Hacker News Reader

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.

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

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.

I'm afraid there will almost always be a tendency towards additive solutions for maintaining existing products simply because nobody will endorse removing features that some customer wants. I'm afraid that an existing product can only add and add further features until a new, slimmed down competitor appears and begins hoovering up most of your customers.

Agreed, it resonates here too. There's probably a little of the "No one ever got fired for buying IBM" mindset[1] in here, somehow.

Engineers, product managers, executives, and consumers alike probably all _tend_ to have a slight bias towards seeing new features as a good thing, for whatever reason.

And even the second-order perception of that bias ("we should probably consider adding this feature, because I think my manager would prefer that we add more features") probably compounds into this problem.

Prioritizing staying up-to-date, simple, bug-free, and in-line with user requirements might lead to better results; achieving and managing that in practice is a whole separate story.

[1] Footnote: not making any claim about the accuracy of this quote :) But it could illustrate the point somewhat, if the prevalance of the quote has, over the years, led to more sales for IBM.

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.

The mathematical analogy has its limits, thought. In analysis, integration (constructive) is analytically much harder then differentiation (destructive).

Good call-out, integration is a very strange beast.

Because integration reduces the dimensionality of the integrand, it is can be seen as subtractive in the sense above.

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.

Yeah, very true, technically log is the "opposite" of exp.

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.

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.

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"

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.

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.

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.

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.'

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.

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.

Looking at the LEGO diagram, here's one thing that's "more to this" that isn't stated: shape.

When I saw the problem description, my natural inclination was to add a support brick in a way that doesn't stick out, to stabilize roof in that direction without altering the building's appearance from both ground level (how the action figures would see it) and air level (how a human would see it). Remove that main pillar instead, and the building is now a meaningfully different one. Additive solution feels much less invasive, and it's something I'd default for in real life, on the assumption the original architects / owners liked the existing looks, and would prefer it not to be visibly altered.

Of course, I then thought, "since looks are technically not a part of the problem definition, I could solve it by removing the middle brick" - but that's my software engineering experience kicking in. The way this thought feels is the same as if I discovered a neat work-minimizing hack when writing code, or in general, how I feel when solving logic puzzles. But in logic puzzles, I already know the whole point is to find the solutions that feel clever.

I think people do have some natural, subconscious intuition for Chesterton's fence - for minimizing unknown unknowns. And to shut it off, it takes more than just saying "removing bricks are allowed", you need to convince them to switch their thinking into puzzle mode, make them explicitly discount the solutions that feel obvious.

It seems kinda ironic to me that you're arguing for people being wired a certain way when the outcome of this (and the other experiments, which involved sandwich recipes) seems to point to the fact that people are not wired the same. I default to the opposite position of yours, ie taking the problem exactly as stated. Indeed, I find it quite challenging when posing some sort of hypothetical to people (eg in debate) and they import additional considerations rather than addressing an issue as stated - although this paper and this conversation give me a better understanding of why that might be.

You're right, I jumped to conclusions in the last paragraph. I definitely shouldn't assume people are wired the same. I myself am not exactly "neurotypical", so I know it first-hand.

So I'll revise my position to: based on my personal experience, observing people I know and general impression I get from reading and hearing things, I believe there is a non-trivial subset of the population, of which I'm a member, that has a sort of subconscious intuition for Chesterton's fence, and do not, by default, take problems at face value.

I hope they'll build on this research as there are benefits and costs to both thinking styles, and as you say there could be great value in knowing which when to make use of which thinking mode, rather than designating one as The Right Way and expecting people to always use it.

By the way I think you might find this paper of interest - about social dilemmas rather than cognitive styles, but I wonder if the results might not be rooted in the same sort of implicit assumption/intuition that you're positing.

https://advances.sciencemag.org/content/2/8/e1600451

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.

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/

(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.)

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.

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.

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.

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.

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.

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.

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.

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

and here we see why css is often write only.

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

True. Try subtracting excessive salt from a meal that you are cooking.