[HN Gopher] Adding is favoured over subtracting in problem solving
___________________________________________________________________
Adding is favoured over subtracting in problem solving
Author : mpweiher
Score : 44 points
Date : 2021-04-07 17:21 UTC (5 hours ago)
(HTM) web link (www.nature.com)
(TXT) w3m dump (www.nature.com)
| samatman wrote:
| A related story:
|
| https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
| elpakal wrote:
| 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
| BurningFrog wrote:
| 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.
| DoreenMichele wrote:
| _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.
| nayuki wrote:
| 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.
| Trufa wrote:
| 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.
| jandrese wrote:
| 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.
| Spartan-S63 wrote:
| 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.
| pessimizer wrote:
| I'm the opposite. Every time I look at my old code for more
| than 5 minutes, it gets shorter.
| cle wrote:
| 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.
| lukifer wrote:
| 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.)
| cle wrote:
| 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".
| mabbo wrote:
| Far worse, they'll comment out no-longer-needed code.
|
| We have git! You can get it back anytime you want! Just delete
| it!
| darkwizard42 wrote:
| 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
| lessthanseventy wrote:
| 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.
| infogulch wrote:
| "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 wrote:
| 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.
| supernova87a wrote:
| 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...
| lqet wrote:
| 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.
| AtlasBarfed wrote:
| I've texted a lot since school. Try to shrink it 33%.
| [deleted]
| slowmovintarget wrote:
| Sculpting, if you will.
|
| Remove all the marble that isn't part of the statue.
| glitchc wrote:
| Doesn't evolution also work this way? Looking at the vas
| deferens, clearly a case of addition over subtraction.
| failrate wrote:
| 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.
| twic wrote:
| 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.
| renewiltord wrote:
| Interesting. People have natural awareness of Chesterton's fence.
| Very cool.
| Traster wrote:
| 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.
| dvh wrote:
| 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.
| photojosh wrote:
| 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
___________________________________________________________________
(page generated 2021-04-07 23:02 UTC)