16 ms·
Adding is favoured over subtracting in problem solving
- nayuki 6y agoAlong 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.
- infogulch 6y ago"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.
- fshbbdssbbgdd 6y agoI 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.
- infogulch 6y agoI tried that until they reviewed it (they're a required reviewer for all PRs...) and forced me to split the refactor into a separate PR and let it sit there for 2 months before asking me to delete it. This occurred multiple times.
- jandrese 6y agoMost 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.
- Spartan-S63 6y agoAdditionally, 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.
- pessimizer 6y agoI'm the opposite. Every time I look at my old code for more than 5 minutes, it gets shorter.
- nayuki 6y agoMe 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 https://github.com/nayuki/Nayuki-web-published-code , for example https://github.com/nayuki/Nayuki-web-published-code/commits/master/avl-tree-list/avltreelist.rs https://github.com/nayuki/Nayuki-web-published-code/commits/... . It's funny you call yourself "pessimizer", because you seem to be good at optimizing.
- cle 6y agoThis 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.
- lukifer 6y agoWhile 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.)
- cle 6y agoI 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".
- lukifer 6y agoSuperb analogy!
- mabbo 6y agoFar worse, they'll comment out no-longer-needed code. We have git! You can get it back anytime you want! Just delete it!
- lessthanseventy 6y agoIf 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.
- simmerup 6y agoIt quickly becomes so out of date that the commented out code provides no use to the reader anyway.
- deleted 6y ago[deleted]
- darkwizard42 6y agocommented 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
- Trufa 6y agoThis reminds me of one of my favorite HN entries: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction 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.
- elpakal 6y agoWorking 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
- BurningFrog 6y agoThe 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.
- failrate 6y agoInteresting, 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.
- twic 6y agoAt 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.
- samatman 6y agoA related story: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- lqet 6y agoI 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.
- deleted 6y ago[deleted]
- AtlasBarfed 6y agoI've texted a lot since school. Try to shrink it 33%.
- deleted 6y ago[deleted]
- slowmovintarget 6y agoSculpting, if you will. Remove all the marble that isn't part of the statue.
- DoreenMichele 6y agowe 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.
- supernova87a 6y agoI 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...
- renewiltord 6y agoInteresting. People have natural awareness of Chesterton's fence. Very cool.
- glitchc 6y agoDoesn't evolution also work this way? Looking at the vas deferens, clearly a case of addition over subtraction.
- dvh 6y agoI 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.
- photojosh 6y agoNPN 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 https://www.analog.com/en/products/lt4320.html
- Traster 6y agoAtleast 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.
- l0b0 6y agoStrange 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 https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence
- vidanay 6y agoPerfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
- arminiusreturns 6y ago"It is not a daily increase, but a daily decrease. Hack away at the inessentials" - Bruce Lee
- euske 6y agoIt'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
- twobitshifter 6y agoThe 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.
- ksm1717 6y agoLike 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!
- yboris 6y agoFrom 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.
- MattGaiser 6y agoAlso, 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.
- sjg007 6y agoYou can start balance bikes at a younger age.
- bigfudge 6y agoThere 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.
- kmanlives 6y agoI 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.
- bigfudge 6y ago
- raincom 6y agoThat'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.
- masswerk 6y agoActually, 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.
- the_local_host 6y agoI wonder if having a bias toward adding things provides an evolutionary edge when the situation gets gnarly and you're starting with nothing working.
- tgv 6y agoI 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.
- guerrilla 6y agoI sure wish software would learn this. Most things just keep getting bloated until they're rewritten.
- jjk166 6y agoAdditive 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.
- iovrthoughtthis 6y agoand here we see why css is often write only.
- KajMagnus 6y agoAnd 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 agoI 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]
- ncmncm 6y agoDeleting code is my superpower.
- ncmncm 6y agoI 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.
- shoto_io 6y agoSide-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.
- PaulHoule 6y agoI am most proud of my code changes when the lines-of-code goes down.
- NanoWar 6y agoWhat if someone removes "your" lines?
- JoshuaDavid 6y agoThat 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.
- PaulHoule 6y agoI'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.
- jawns 6y agoA few non-paywalled articles related to this research: https://www.sciencedaily.com/releases/2021/04/210407135801.htm https://www.sciencedaily.com/releases/2021/04/210407135801.h... https://www.sciencenews.org/article/psychology-numbers-people-add-default-subtract-better https://www.sciencenews.org/article/psychology-numbers-peopl...
- hannob 6y agoInteresting 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.
- jrvarela56 6y agoMade me think of Rich Hickey's talk about versioning. "Avoid breakage, accrete!" https://www.youtube.com/watch?v=oyLBGkS5ICk&t=2462s 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.
- deleted 6y ago[deleted]
- rossdavidh 6y agoAn 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.
- deleted 6y ago[deleted]
- imgabe 6y agoThis 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.
- wilg 6y agoIt seems reasonable that one of the reasons people choose inefficient solutions might be that they make incorrect assumptions.
- imgabe 6y agoMaybe 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!"
- wkyle 6y agoThe 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.
- Closi 6y agoAbsolutely - 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).
- monkeywork 6y agoYou 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.
- starky 6y agoIt 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.
- KajMagnus 6y agoOr if someone who had been designing airplanes for 40 years, shifted to writing software?
- ggm 6y agoSculpting 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.
- taylorlunt 6y agoI wrote about this here: https://taylor.gl/blog/6/ https://taylor.gl/blog/6/ It seems to be psychologically easier to justify adding things than removing them.
- anonytrary 6y agoAddition 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.