Hacker News new | past | comments | ask | show | jobs | submit login
Adding is favoured over subtracting in problem solving (nature.com)
186 points by mpweiher 3 days ago | hide | past | favorite | 142 comments

Additive solutions are fundamentally easier than subtractive ones.

If removing something, you run into the problem of chesterton's fence: if you don't completely understand why it was there in the first place, you could potentially be messing something up which you do not anticipate. If you have n elements, finding a subtractive solution requires understanding how all of them interact with eachother, which scales like O(n^2). On the other hand an additive solution only requires you to understand your new element and how it affects the system, which scales O(n).

Consider the relative difficulty of removing versus placing a jenga block.

On top of this, think about how complex systems tend to be formed. Typically multiple people each with different needs make proposals and at the end you have a consensus which is, if not ideal, at least acceptable to everyone. Theoretically, if there was unnecessary and harmful stuff in there, either someone would have complained and already gotten it removed or there is some interest group that has a good reason for keeping it there. An addition, on the other hand, may have never been considered the first time around, and can be carefully tailored to minimally influence the status quo beyond the desired change.

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.

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

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.

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.

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.

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.

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.


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.


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

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.

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.


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

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.

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


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

we propose that the bias towards additive solutions might be further compounded by the fact that subtractive solutions are also less likely to be appreciated. People might expect to receive less credit for subtractive solutions than for additive ones. A proposal to get rid of something might feel less creative than would coming up with something new to add, and it could also have negative social or political consequences — suggesting that an academic department be disbanded might not be appreciated by those who work in it, for instance.

I think there is probably a huge social component. Leaving existing stuff alone and adding something will get a lot less push back than removing something.

It is also a risk averse solution. You have to understand a problem space fairly well and be confident you are correct in order to effectively cut and have any hope that people will generally be happy with the outcome.

It can be done, but it tends to be a lot harder.

So it is also something we are simply inculcated with because adding stuff is the thing we experience the most often as the way things get handled.

Strange that the article doesn't mention Chesterton's Fence[1]:

  > [T]he principle that reforms should not be made until the reasoning behind the existing state of affairs is understood.
If removing things is allowed, it would be just as valid to take the roof off of the structure entirely, or to demolish everything underneath it and just leave the slab on the ground.

Another way to look at it is that adding things has a known cost in this experiment, but presumably any cost of removing something is not mentioned. If adding three pillars costs 30 cents, and removing one pillar has non-zero, unknown cost, which one would you choose?

[1] https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence

I’m going to use this every time I see suggestions for personal convenience masked as suggestions for improvement.

You have to use it with caution though, otherwise it just becomes an excuse to never get rid of cruft.

I have produced a fair amount of professional and belletristic texts since I have left school. The most difficult part is not the production of text, but the deletion. It is also the most effective way to enhance the writing quality. A general rule of thumb: whenever you have finished a text, try to cut it down by 1/3.

Sculpting, if you will.

Remove all the marble that isn't part of the statue.

I've texted a lot since school. Try to shrink it 33%.

From the article:

> Given the benefits of balance bikes, why did it take so long for them to replace training wheels?

Answer: because buying a dedicated bike just to train how to use a bike is not something you can do unless you're affluent. Adding or removing training wheels is cheap and means you can keep using the same bike.

??? It's even cheaper to remove the pedals and cranks from the kid's bike and to lower its saddle. Instant balance bike.

Having had the pleasure in training three kids how to ride a bike, forget training wheels, or taking the pedals off!

find a reasonable long grass hill - not to too steep, but steep enough to allow a kid to go down the hill riding the bike with out pedalling.

and then goto the top of the hill and let them go down the hill on the bike. Once they master the balancing part of going down, they seem to pick up the art of turning the pedals at the end of the hill to keep going (if not, explain what to do)

advantages: doesn't hurt when they fall off, gets them used to rough terrain. it becomes fun once they start to master the balancing bit

We did exactly this for my first son.

We had been trying for weeks without result, both with trainer wheels and to run behind with an attached handle. Then one day we unmounted the pedals and lowered the seat... after just an afternoon we could reattach the pedals and he was now cycling on his own!

I did this with my daughter. She was riding her bike within the hour. I made a game of it with chalk on the street. She how far she could glide, then mark it. Keep repeating... Eventually put on the pedals, and off she went.

It’s much easier to add and remove training wheels than mess with an integrated part of the design.

Eh? They are bolted on with screws and get regulary replaced. It's not any difficult than removing training wheels.

Nope, thread starter has a point here. It's not only pedals and screws. You probably would like to remove the front gears and therefore the chain, that requires you to remove the whole rear weel. What if you have a back-pedalling brake hub. Besides that now you have a "hole" in the gear area, maybe full of oil, Also the bike designed to perfectly run with the full gear on. And so on... you may not want to tamper that "perfectly" aligned system if your kid is playing with it. Nope...it's not just about removing the pedals.

Or just remove the pedals and tape one of the cranks to the chain stay so they don't spin and catch the trousers. Did this with my daughter's bike and it held up fine for the month she pootled on it until she was ready to pedal.

Why do you need to remove any gears? You just unscrew the pedal from the arm and that's it.

I'm really not understanding why you think it's necessary to remove more than that.

I've done it on quite a number of different bikes, it really is quite easy.

You'd think so, but having taken apart a couple of bicycles I gotta say it's far more complicated than say taking apart a PC. There are so many seemingly pointless steps involved like removing C clips that don't belong and solving some topological problems to get the chain out. Notice how the chain and the triangle frame are interlinked.

I have no idea how these victorian steam punk contraptions are assembled and sold at a <$100 price point

Are you maybe thinking about cranksets? All it takes to remove a pedal from the crank is an adjustable spanner.

Define "regularly". I've replaced pedals on bicycles I've owned exactly once in my lifetime. That includes the 4 year period prior to COVID that I commuted by bicycle and caltrain. It was much more difficult to loosen the bolts and get them re-fastened than the training wheels on my oldest's bicycle. Not to mention the handling of the chain.

I switch between toe clips(for commuting) and cleats(for longer rides) at least once a month. Why would you need to handle the chain? Pedals are attached to cranks.

And usually the proper way to mount training wheels is higher than the ground by a couple inches so they only touch the ground when the bike leans a little, encouraging balance.

I tried that, and the kid will then just ride the bike with it leaning all the way to one side till the wheel hits the ground.

I'd really like to see training wheels with adjustable spring tension. Gradually make the spring weaker so the training wheels have less effect every couple weeks, until they aren't really doing anything at all.

How does the kid steer? Bikes need the front wheel to be pretty close to perpendicular with the ground. Tilted over, you'd just go in a tight circle forever, and trying to turn would lift you off the training wheel.

You can still steer, since it is supported by the training wheel then the front wheel can be turned any direction as it isn't needed to be pointing a specific way to maintain balance.

Also I'm talking about the training wheels being lifted an inch or two. Causes a lean of maybe 10 - 15 degrees I'd guess.

Well there's your problem, you're supposed to lift up the training wheels over time. At the beginning they may be used all the time but by the end they should only be there to catch a bike that's falling over.

If the kid would alternate which training wheel is touching, then that would work. But once a side is picked they seem to center their balance between the back wheel and the one training wheel. I started off just barely raising it, and every couple weeks would adjust it another quarter inch or less. eventually they picked a side to lean and stayed with it.

That is where I was hoping to find spring loaded training wheels so that it forces the kid to constantly try to balance. Start off with really stiff springs and then weaken them over time.

Wow you should patent that. Or do a kickstarter. That sounds pretty useful.

Take the pedals off and lower the seat. Tell kid to use his feet. Hey presto, it's a balance bike.

I’ve had the privilege of ‘training’ three kids to ride bikes. As those of us who ride bikes know, there is no way to explain how to do it. Running alongside the kid with a hand on them (or on the handlebars) is useless. Training wheels are useless. The only way for the kid to ‘get it’ is to allow the bike to fall: only when they start to fall, and they instinctively jerk the handlebar the other way, will their muscles ‘understand.’

It only took a couple hours with each kid... pushing them up to speed and then letting go. They’d fall, there would be tears, and we’d try it again. And, then, after several scraped knees and bruised shins, that magical moment would occur when some little cluster of neurons finally makes the new connections, and voila... they’d be bike riders. All the tears and frustration would be replaced by euphoria.

Clearly a two or three year old, perhaps, is better off with a scooter or balance bike. But, as an old fart, watching 7 and 8 year olds in the park riding ‘balance bikes’, I get the sneaking suspicion that the parents are stretching out a couple-hour process to a couple-month or year process merely because they can’t permit themselves to let the kid wipe out.

Don’t even get me started with swimming...

I trained two kiddos using the parent's method.

Taking the pedals off seemed functional equivalent to a balance bike, and I taught my 4 and 5 year old to ride their bikes the same afternoon.

Same with swimming.

It's kinda goody to judge other parents, tho. A lot of stuff that is easy for me is hard for other folks. But I've been divorced twice, and a lot of folks haven't. So very difficult to judge.

I don't, in general, think that your description of why folks aren't teaching the kiddos using your method is accurate. IME, most folks are just ignorant that it can be done at all.

Didn’t mean to come across as TOO judgmental... obviously I don’t assume to know the details of every parent-child relationship in the world when it comes to bikes.

But, getting back to the article, I’m somewhat dubious about the assumption that humanity just stumbled upon the idea of a balance-bike due to some mental fog that prevented us from considering it.

I think it might be more likely that parenting-styles have changed a bit and there is now a market for a bike-teaching tool that is safer. In other words, I suspect that if you presented a dad in the 1950s with a balance bike and explained it was a tool to more gradually and safely get a child pedaling, he might scratch his head and say, “why would I use that? When the kid is old enough to ride a bike, I’ll be able to show him how in a single afternoon.”

This also happens when there is a younger sibling who shares the bike.

Also, the assumption of balance bikes is that you have lots of time/energy to let the kid learn.

Training wheels make a bike rideable very quickly.

I thought a balance would be great, but neither of my kids liked the balance bike we bought. They rode with training wheels for quite a while.

What got them riding without training wheels was learning to ride Razor scooters. One afternoon when I saw them both riding sweeping S curves on their scooters, I took their training wheels off. At 6 and 7 1/2 yrs, they when from total terror on their bikes to riding comfortably in a few hours. It only took a few rides with me running alongside holding on (continually holding on less each time).

It was amazing.

But riding with training wheels looks miserable... it destroys the smoothness and joy of a bike. I'm surprised kids want to persist with it at all... My kids loved balance bikes (i.e. normal bikes with no pedals) because they don't have the resistance and weird balance issues of a tiny third wheel.

You can start balance bikes at a younger age.

There are great videos of a Swedish three year old on a half pipe on a balance bike! My kids were not so fearless, but my son did a 8 mile ride (flat ex railway line) on a balance bike when he was 3. And before anyone accuses me of pushy parenting... we didn't make him! The plan had always been for my wife to ride with him separately, but he insisted on coming the whole way with his two siblings. It was a really memorable day.

Can you take the pedals off a regular bike to make it into a balance bike? Or is there something special about the balance bike design?

Yes, though you need to lower the saddle as well as remove the pedals.

IME the the balance bikes are about the same price as a set of training wheels. And also re-usable - my youngest two kids used the same balance bike.

When I was young, we just used learnt on a regular non-adapted bike. It usually involved a few minor scrapes and bruises, but you learnt very quickly.

It seems like your answer suffers from the very bias being described, because you don't have to "add" a balance bike to your inventory. You can just "subtract" the pedals off the one you've got.

I don't think a bike with the pedals removed is equivalent to a balance bike. The height matters right?

Kids bikes all have adjustable height seats. Lower it. Done.

The strategy that is overlooked is addition by subtraction.

See C++ and most long term software products. I think a difference with software is that when properly designed additive features can lay dormant if unneeded. Not many need Mx-butterfly in emacs, but if you do, it’s there.

Like the other discussion here about how it’s even better to be able to take the pedals off a bike and lower the seat compared to buying a new balance bike. Low coupling, swappable parts, configurable, add or subtract ad infinitum... you can get the best of both worlds in any domain!

Along similar lines, most developers are afraid of deleting code. They would rather pile on more code to try to add a parallel system or patch around a problem instead of fixing or deleting the problem itself.

This fear is well-founded. Changing a system is a lot riskier than leaving it alone and building things around the periphery. Changing it requires a deep understanding of the implications of the changes, the impact on consumers/clients/other systems, etc.

Doing that continuously does accrete complexity. But there is often a higher cost to fixing a problem rather than working around it.

While you’re completely correct, I’ve also observed an anti-pattern where people become afraid to touch load-bearing code if it “works”, compounding over time into a brittle codebase and piles of hacks to work around shortcomings in infrastructure. Assuming it meets the risk/cost/reward trade-offs, I’ve found it’s preferable to rip the bandaid off and refactor ASAP, rather than allowing “fear-driven development” to take root. (Obviously, a robust test suite greatly lessens the risks.)

I completely agree, and I do the same thing too. If there's something that people are scared to touch, I immediately want to change something fundamental in it so we can get un-scared of it. I'd rather have a controlled demolition than a "rapid unscheduled disassembly".

Superb analogy!

"refactor" is a trigger word for my tech lead now. It's exhausting when every attempt to improve the codebase is a battle. When I'm tasked with fleshing out the third bugfix story for a feature that I refactored in 30 minutes 2 months ago, but the PR for it which demonstratively would have solved all of them is still lying on the floor... a little part of me dies inside.

I try to avoid calling anything a refactor. I just describe it as part of the fix.

Similarly I never try to convince management that I need time to improve code quality... I just do it to code that I’m touching. I think people who don’t know the details have the (often correct) heuristic that work that doesn’t deliver incremental results is just an excuse to waste time / sandbag, so I just don’t bother trying to convince about the ROI.

Most people don't add more code just for fun. If you're deleting something you had better have a solution to whatever problem that code was solving in the first place.

It definitely makes sense to delete code in some cases, but most of the time the solution requires the addition of code. This makes sense, the size of a program doesn't tend towards zero over time. They tend to grow as new features are necessary and yet the old features can't be retired without causing disruption.

Additionally, time pressure constraints often prevent refactoring and other code-minimizing opportunities. Usually, there isn't enough time given to paying down tech debt or refactoring swaths of code to allow for the overall reduction in line count while delivering new features.

That reality, though, isn't always possible, and software will always trend towards larger line counts and more complexity.

This reminds me of one of my favorite HN entries: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

>> Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.

I'm the opposite. Every time I look at my old code for more than 5 minutes, it gets shorter.

Me too - I enjoy reviewing my existing work, and slowly over months and years with fresh eyes, I modify my code to be shorter or clearer. Some evidence exists in the history of https://github.com/nayuki/Nayuki-web-published-code , for example https://github.com/nayuki/Nayuki-web-published-code/commits/... .

It's funny you call yourself "pessimizer", because you seem to be good at optimizing.

Far worse, they'll comment out no-longer-needed code.

We have git! You can get it back anytime you want! Just delete it!

If it is deleted instead of commented out I would have to know it used to be there in the first place to track it down in the git history.

It quickly becomes so out of date that the commented out code provides no use to the reader anyway.

commented out code helps any future developer either heed a past warning or learn from a past example. I think there are uses to commenting vs. deleting

I am most proud of my code changes when the lines-of-code goes down.

What if someone removes "your" lines?

That is frequently very nice, because if something breaks or requirements change in code you wrote you will usually be the one who has to make the update -- if lines of code you wrote are removed, that means less code you have to worry about maintaining later.

Of course, the niceness only holds if your code is being removed because it is no longer needed. Having your code removed because it doesn't work properly and is being replaced with code that does work properly is not a nice feeling.

I'm more concerned with moving the ball forward for the team than I am with feeling good about what I did in the past.

I'd prefer to do it right the first time, but given that, I'd prefer somebody make a fix that is shorter rather than one that is larger.

This seems immediately flawed. If I see one pillar holding the roof off the base, I assume there is a reason the roof should not be resting directly on the base or they wouldn’t have put the pillar there in the first place. Maybe it needs airflow, or light, or they just like the aesthetics.

I think all this proves is that if you present people with a partial design that points in one direction, they’ll continue in that direction.

The pillar experiment from the paper isn't fully explained in the article. The instructions stated "You may alter the structure however you want".

The experiment was run with two groups, both of which were given equal costs on addition – "Each piece that you add costs ten cents". There was also a group given a 'subtraction-cue' where the instructions mentioned that "removing pieces is free and costs nothing". Increase from 41% to 61% use of subtractive method.

There was a cost to addition, so the optimal solution for both groups was removal of the pillar.

Absolutely - also it’s unclear if you are allowed to remove things what solutions would be allowed / disallowed.

For instance do I have to have a roof? Could I just balance the brick on the structure?

Can I remove the whole structure, put the roof on the floor next to the person, and just put the brick on that?

If not, Can the guy lie down to clear extra space so I can remove another layer?

Could I just have the guy lie down and surround him with one layer of bricks and then put the roof on that?

It’s not immediately obvious to me that all the above solutions would be allowed as an answer, because the question is to put a brick on “the structure”, so surely if I remove some of “the structure” then that’s hardly putting a brick on “the structure”, it’s putting a brick on “a structure”.

I assume by the time you have put the guy in effectively a coffin buried under a brick then someone would argue that the purpose of the structure is lost, but you could also argue that somewhat if you removed the roof height (a higher roof could be a feature).

Becoming aware that people "by default" think like you describe — plus reflecting about if it's appropriate, and maybe doing something about it — is a bit the point with the article?

Look at the last paragraph:

> policymakers and organizational leaders could explicitly solicit [...] proposals that reduce rather than add

I disagree with their conclusion, because if you changed the question to say “the structure must be at least 3 Lego blocks high” without telling people to subtract blocks then I think it would probably solicit similar results.

Their conclusion is that people will add rather than take away, so you should tell people to take away. My conclusion is that people will add rather than take away if not provided enough information about the problem space. I think the solution is to better define the problem, otherwise you can come up with lots of proposals that aren’t suitable.

If I don’t know if making the guy lie down is allowed I’m going to have to make an assumption and either under-optimise or over-optimise.

My view is saying you can remove bricks implies that roof height isn’t important, which changes the users assumption on requirements. The learning should be more clarity on requirements, rather than just “ask people to reduce rather than increase”.

Additionally, if you changed the rule and said “participants will be scored based on the number of blocks removed”, I assume you would also get people creating silly scenarios like the ones I described and wholly unsuitable designs. This is more realistic in the real world where less material = less cost.

It seems reasonable that one of the reasons people choose inefficient solutions might be that they make incorrect assumptions.

Maybe so, but that wouldn’t be a “preference to add rather than subtract”

Also in personal experience as an engineer working with architects, suggestions to make radical alterations to the form of the structure are usually not well received...

It's not an unreasonable assumption to make. Like if you present someone with the sequence "1, 2, 3..." and ask them to continue it, they're going to say "4". It doesn't prove anything to say "Aha! The sequence was actually "1, 2, 3, 2, 1 behold your preference to add rather than subtract!"

I think a reason for this phenomenon is that removal of something generally requires an understanding of the intent and behaviors of the system as it is (and better yet, why it was built that way, and what levers you have available to you to modify it, or constraints that you cannot change).

Much easier (or takes less thought, or more easily glosses over important complex unappreciated issues) just to add something that you think will solve the individual problem at hand...

Interesting, I thought it was just me who had to overcome negative connotations to subtraction and division. It is only in the last 15 years that I learned to treat all arithmetic neutrally.

At some point, i started to think of subtracting as finding the difference, and dividing as finding the ratio. Those seem much less negative; indeed, they feel like going to a (very slightly!) higher level of abstraction.

Working at a company which practices this glorious thing called SAFe Agile, this article makes a lot of sense! So many people, so many teams, all continuously adding features to a codebase just because the methodology says you should - how does that work out in the long run? Engineers need time to remove code, we need time to garden and take care of debt. However I find fighting for these things to be a challenge largely skewed by the freight train that is SAFe and its ceremonies, and maybe this is the psychological fuel that powers it.

# rant over

The architecture/design phase in XP is when everything is working, and you refactor the code to be better.

It was absolutely fantastic when I understood how to first write the code, and then design it!

Sounds like the SAFe people left that part out.

It would be interesting to compare the results here between people with a product design or manufacturing background vs. someone with different backgrounds.

I work in the mechanical design space and definitely solve problems with additive and subtractive solutions all the time, and it depends a lot on the context of the solution. This thinking almost certainly continues to other problems that I encounter in everyday lift.

Machining, for example, is subtractive by nature, so initial solutions to a problem are usually additive since it costs money to subtract more, but something already made tends to be subtractive as you can't easily add material back.

Conversely, for molded/cast parts, your design is initially subtractive as you want to use as little material as possible, but after the part is tooled, it becomes significantly more difficult to remove material, where adding material through modifications to the tool are relatively simple. Designing in a "steel safe" condition is a very common tactic for these types of parts.

Or if someone who had been designing airplanes for 40 years, shifted to writing software?

Made me think of Rich Hickey's talk about versioning. "Avoid breakage, accrete!" https://www.youtube.com/watch?v=oyLBGkS5ICk&t=2462s

Subtraction increases chances of breakage.

This approach increases maintenance costs (duh) but form customers PoV, it's better if something I rely on doesn't stop doing it.

Interesting this shows up here. I saw an article covering this study this morning and thought "yeah, that's how IT security works" (or does not work).

Everyone agrees if you say "complexity is bad for security". But somehow it's still incredibly unpopular in practice. Most commercial security products are all about adding more stuff, and they don't seem to go bankrupt.

Interesting. People have natural awareness of Chesterton's fence. Very cool.

Actually, in my youth training wheels were generally considered to slow the learning process (and therefore rather seldom used, maybe even frowned upon, where I grew up.) In light of this, the new thing about balance bikes is the omission of pedals. – Which also highlights an interesting feature of our current ways of approaching things.

Atleast for the example question I feel like it's like one of those stupid interview questions. It's a perfectly valid approach to accept the problem as it is - the clear implication is "here's the problem, your mechanism for fixing the problem is to add bricks at X cost, go fix". If you want to subtract fine, but there's a shed load of things you need to consider - why was the pillar there in the first place, is the base structurally sound, etc. Again with the white/green square thing, people probably simply read the white as "unset" and green as "set" so they don't think to "unset" something becaues it may not be an obvious option - and, this is important, it's a trivial test they aren't invested in.

At the very least I would expect a symmetric experiment where they imply you should be removing bricks and can't add.

An additional reason (at least in IT): adding things, also adds keywords to my resume, whereas removing things generally does not. The incentives created by our hiring and pay practices here, are all the opposite of what they should be.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

-Antoine de Saint-Exupery

"It is not a daily increase, but a daily decrease. Hack away at the inessentials" - Bruce Lee

It's one of my favorite Saint-Exupery quotes.

This is also relevant: (from my vague memory)

"Any fool can add things. Subtracting, however, requires a genius." - Greek saying

I have discovered how to teach kids to ride a bike in, literally, seconds. No exaggeration! It has worked numerous times.

For many decades we have lied to them about how to ride: "steer with the handlebars", a reliable recipe for violent spills.

I tell them to use the handlebars to stay up, and lean to steer. Off they go! It is amazing to see, every time.

I wrote about this here: https://taylor.gl/blog/6/

It seems to be psychologically easier to justify adding things than removing them.

You can see this as well in TTRPG's. There is a firm divide between those who use descending or ascending armour class in D&D editions, with those who prefer ascending claiming it's simply easier.

I have similar theory regarding bipolar junction transistors. In schools NPN is often taught first in great detail and PNP is then just glanced over. That's why most circuits use NPN and fewer use PNP because people understand NPN better.

NPN BJTs (and N-channel FETs) are more efficient (and cheaper), and IIRC it was an enormous difference years back.

This is to the extent that many integrated circuits that drive external transistors will actually have a charge pump to allow them to generate the voltage greater than the main supply in order to use N over P on the high side. [0] is an example of one I was looking at recently.

It's also tricky to match N and P transistors because there's always tradeoffs on the P side, so if you can just use Ns across the board it can make the analysis component selection easier.

Arguably they are just glanced over because they really do just apply the same principles. I still would reach for a P-channel to do power rail switching on my lower power designs, fwiw, but that's about the only situation.

[0] https://www.analog.com/en/products/lt4320.html

Addition is not as cathartic as subtraction. When you subtract something and everything still works, it means you're closer to the truth. Ptolemy's epicycles come to mind.

Sculpting is probably the main historical subtractive process most people know of. And, its notoriously hard.

Printing techniques which depend on removing things intaglio is also notoriously hard to learn.

Side-note: I can confirm, that balance bikes make it way more easy for children to learn biking. Our first son had the side wheels and our second and third one had a balance bike.

I wonder if having a bias toward adding things provides an evolutionary edge when the situation gets gnarly and you're starting with nothing working.

I sincerely hope that the discussion of the first experiment in the article is wrong, because that absolutely does not support the hypothesis (apart from the fact that it looks to be designed to falsify the hypothesis' opposite). And everything seems to be centered around Lego blocks, which, as we all know, is the perfect representation for all of our problems. Well, Nature never had a great record in psych publications, anyway.

Doesn't evolution also work this way? Looking at the vas deferens, clearly a case of addition over subtraction.

I sure wish software would learn this. Most things just keep getting bloated until they're rewritten.

That's why scientific revolutions happen, since researchers in the existing research program(paradigm) don't want to give up the core hypotheses, by protecting these core hypotheses by auxiliary hypotheses to withstand any criticims, anomalies, etc. Imre Lakatos calls these auxiliary hypothes protective belt. It is very easy to give up what one has mastered.

Deleting code is my superpower.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact