[HN Gopher] Adding is favoured over subtracting in problem solving
___________________________________________________________________
Adding is favoured over subtracting in problem solving
Author : mpweiher
Score : 105 points
Date : 2021-04-07 17:21 UTC (1 days ago)
(HTM) web link (www.nature.com)
(TXT) w3m dump (www.nature.com)
| PaulHoule wrote:
| I am most proud of my code changes when the lines-of-code goes
| down.
| NanoWar wrote:
| What if someone removes "your" lines?
| JoshuaDavid wrote:
| 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.
| jawns wrote:
| A few non-paywalled articles related to this research:
|
| https://www.sciencedaily.com/releases/2021/04/210407135801.h...
|
| https://www.sciencenews.org/article/psychology-numbers-peopl...
| ncmncm wrote:
| 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.
| raincom wrote:
| 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.
| 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.
| vidanay wrote:
| Perfection is achieved, not when there is nothing more to add,
| but when there is nothing left to take away.
|
| -Antoine de Saint-Exupery
| arminiusreturns wrote:
| "It is not a daily increase, but a daily decrease. Hack away at
| the inessentials" - Bruce Lee
| 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.
| hannob wrote:
| 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.
| twobitshifter wrote:
| 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.
| ksm1717 wrote:
| 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!
| [deleted]
| masswerk wrote:
| 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.
| 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.
| nayuki wrote:
| 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.
| 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.
| simmerup wrote:
| It quickly becomes so out of date that the commented out
| code provides no use to the reader anyway.
| 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.
| jjk166 wrote:
| 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.
| sean_pedersen wrote:
| I don't get how the additive solution does not require to
| understand the whole system and all it's interactions. If I
| place a jenga block I need to understand the static properties
| of the whole jenga tower to prevent collapse.
| [deleted]
| jerf wrote:
| 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.)
| [deleted]
| teachingassist wrote:
| A Jenga turn requires you to remove a block from the tower,
| and then add the same block to the top of the tower.
|
| You seem to be claiming that you believe these two actions
| (subtracting and adding) are theoretically of equal
| difficulty - but in practice, they are not equally difficult.
|
| It's far more common, almost to the point of certainty, that
| you will lose by removing an existing block. You are vastly
| more constrained in your actions when removing blocks that
| are already placed.
| Twisol wrote:
| 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.
| jjk166 wrote:
| 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.
| anigbrowl wrote:
| _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.'
| agumonkey wrote:
| 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
| dvt wrote:
| 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.
| iovrthoughtthis wrote:
| and here we see why css is often write only.
| gamegoblin wrote:
| Your comment struck a chord with me from what I've seen in
| various enterprise codebases, and it also seems to have a
| flywheel effect.
|
| That is, it's possible for a small team of experts to keep a
| piece of software in a constant good, small state by always
| balancing additive vs subtractive solutions, because everyone
| has a fairly complete model of the entire project in their
| head.
|
| But if there is any tendency towards additive solutions (e.g.
| due to personnel churn, deadline crunch, etc), the project
| becomes larger and thus harder to keep a model in one's head.
| This makes subtractive solutions harder to think of and
| implement, which results in more additive solutions, thus
| exacerbating the problem.
| spondyl wrote:
| 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.
| CobrastanJorji wrote:
| 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.
| bordercases wrote:
| Counterpoint: adding locally is easier than subtracting
| locally, but subtracting globally is easier than adding
| globally.
|
| Blowing up a complex codebase to start again is an easier
| change than re-architecting the codebase through the
| investigation of its parts.
| inglor_cz wrote:
| True. Try subtracting excessive salt from a meal that you are
| cooking.
| 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]
| [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.
| the_local_host wrote:
| 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.
| 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.
| jrvarela56 wrote:
| 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.
| renewiltord wrote:
| Interesting. People have natural awareness of Chesterton's fence.
| Very cool.
| tgv wrote:
| 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.
| yboris wrote:
| 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.
| didgeoridoo wrote:
| 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?
| fanf2 wrote:
| Yes, though you need to lower the saddle as well as remove
| the pedals.
| cameronh90 wrote:
| 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.
| gandalfian wrote:
| Take the pedals off and lower the seat. Tell kid to use his
| feet. Hey presto, it's a balance bike.
| [deleted]
| lurquer wrote:
| 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...
| scarecrowbob wrote:
| 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.
| lurquer wrote:
| 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."
| chapium wrote:
| This also happens when there is a younger sibling who
| shares the bike.
| burnte wrote:
| 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.
| derekp7 wrote:
| 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.
| mrfusion wrote:
| Wow you should patent that. Or do a kickstarter. That
| sounds pretty useful.
| jjk166 wrote:
| 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.
| derekp7 wrote:
| 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.
| jjk166 wrote:
| 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.
| dang wrote:
| That "the article" was
| https://www.scientificamerican.com/article/our-brain-
| typical....
|
| (We merged https://news.ycombinator.com/item?id=26740085
| hither.)
| SeanLuke wrote:
| ??? It's even cheaper to remove the pedals and cranks from the
| kid's bike and to lower its saddle. Instant balance bike.
| zikduruqe wrote:
| 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.
| tobbebex wrote:
| 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!
| 123pie123 wrote:
| 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
| sidlls wrote:
| It's much easier to add and remove training wheels than mess
| with an integrated part of the design.
| hcho wrote:
| Eh? They are bolted on with screws and get regulary
| replaced. It's not any difficult than removing training
| wheels.
| NavinF wrote:
| 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
| hcho wrote:
| Are you maybe thinking about cranksets? All it takes to
| remove a pedal from the crank is an adjustable spanner.
| y42 wrote:
| 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.
| hcho wrote:
| 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.
| sidlls wrote:
| 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.
| hcho wrote:
| 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.
| wbeckler wrote:
| 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.
| ianwalter wrote:
| I don't think a bike with the pedals removed is equivalent to
| a balance bike. The height matters right?
| [deleted]
| djrogers wrote:
| Kids bikes all have adjustable height seats. Lower it.
| Done.
| MattGaiser wrote:
| 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.
| bigfudge wrote:
| 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.
| kmanlives wrote:
| 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.
| sjg007 wrote:
| You can start balance bikes at a younger age.
| bigfudge wrote:
| 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.
| grahamburger wrote:
| 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.
| l0b0 wrote:
| 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
| tchalla wrote:
| I'm going to use this every time I see suggestions for personal
| convenience masked as suggestions for improvement.
| shoto_io wrote:
| 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.
| [deleted]
| guerrilla wrote:
| I sure wish software would learn this. Most things just keep
| getting bloated until they're rewritten.
| ncmncm wrote:
| Deleting code is my superpower.
| 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
| rossdavidh wrote:
| 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.
___________________________________________________________________
(page generated 2021-04-08 23:01 UTC)