[HN Gopher] Simplicity is an advantage but sadly complexity sell...
___________________________________________________________________
Simplicity is an advantage but sadly complexity sells better (2022)
Author : 7d7n
Score : 331 points
Date : 2024-05-05 17:17 UTC (1 days ago)
(HTM) web link (eugeneyan.com)
(TXT) w3m dump (eugeneyan.com)
| austin-cheney wrote:
| Incompetence also qualifies billing a client substantially more
| time for a given work effort completely without fraud.
| nelsondev wrote:
| This idea also applies to software sales.
|
| e.g. A bloated, overly complicated, CMS is easier to sell to a
| company as a solution than a sleeker, cleaner solution.
|
| "If you can't dazzle them with brilliance, baffle them with
| bullshit"
| masklinn wrote:
| Clients will actively seek it out.
|
| My boss used to try and make clients understand they could do
| minor adaptations of their workflows, and adapt a few labels of
| the product and they'd be done and productive in a few days,
| and they'd requests weeks of system customisation instead.
| ervine wrote:
| Yep - seems clients have a knack for asking for the most
| complicated way of doing things.
|
| Frustrating as a developer that is already slammed, but good
| for the business overall. But how many times have we all
| built extremely complex features that never ever get used.
| ghaff wrote:
| Clients also don't want to be told they'll have to adapt
| their workflows/processes. A long time ago the COO of our
| _very_ small company was adamantly opposed to replacing
| Exchange (which went down with some regularity) with a SaaS
| because they 'd have to make changes to the filing system
| for their contracts (was before Google had nested labels).
| The CEO overrode them but the issue was clearly that they
| didn't want change.
| knallfrosch wrote:
| A client that adapts their workflow to a readily
| available software and customizes the rest isn't a client
| at all.
|
| First: I think you guys misunderstand the very nature of
| business. All customers have problems they want YOU to
| solve in exchange for money. The rest of the people just
| don't contact you. It's kind of the "survivorship bias."
|
| Secondly: Within an organization, if a project manager
| has a budget and is tasked with solving a problem, "let's
| make IT adapt our systems" is not an acceptable solution.
| Most of the time all you have is money, not software
| developers or IT staff. They are hopefully working on
| their core product and not on billing or sending emails.
|
| Thirdly: Don't underestimate the ongoing support that
| stems from point two. If you ever make adaptions to
| someone else's software, you know what's going to happen
| when there's an incident and you call support: They are
| going to blame your customization, they are not going to
| understand your needs or customization and they'll kindly
| string you along until you fix it yourself using precious
| staff ressources. It is _much_ easier to let someone else
| do everything from start to finish and pick up the phone
| when there 's a problem.
| hgs3 wrote:
| > seems clients have a knack for asking for the most
| complicated way of doing things
|
| Sometimes clients don't know what they want. Sometimes you
| have to show them. "If I had asked people what they wanted,
| they would have said faster horses" ~ Henry Ford.
| mindwok wrote:
| The enterprise buying process is geared to achieve consensus
| and reduce the risk of purchasing the wrong thing. As a
| result, dozens of groups get invited to participate and all
| throw their requirements into the ring. Vendors then do
| contortions to try and sell to these customer, and you end up
| with software that tries to be everything to everyone.
| galdor wrote:
| In technical organizations (all organizations really), simplicity
| is also a hard sell: you need people in charge with the ability
| to say "no" to a lot of ideas. And no one wants to be on the
| receiving end of a "no".
|
| Those who favour simplicity will always be outnumbered, and their
| position will be untenable unless the entire top management team
| agrees. Good luck with that.
|
| It is also one the reasons why the BDFL model works so much
| better: you need the ability to say "no" a lot.
| dave4420 wrote:
| I've not found this to be the case.
|
| I've argued at work before for us to deliver a simpler subset
| of a feature, that delivers most of the value sooner, then to
| assess later whether we actually need the rest of the feature.
|
| This is also why I'm confident about my continued employment in
| the age of AI: CEOs are always asking how we can deliver
| faster. They might not be able to afford more software
| engineers, but they can always use more.
| tolmasky wrote:
| There is also a secondary effect where more complex systems
| generate a bunch of surrounding materials: tutorials, videos,
| etc. It also creates job security for the people who learn it, as
| they have a necessary skill and responsibility in the company, as
| opposed to something that "just works" which doesn't require
| that.
| RetroTechie wrote:
| https://en.wikipedia.org/wiki/Full-employment_theorem
|
| So many people in IT have a job _because_ if software were
| constructed that would be both simple & Just Work, those jobs
| wouldn't exist.
| j45 wrote:
| It would seem that way, but organizations that are truly
| about improving and growth would have the people available to
| help improve other things.
| namaria wrote:
| Bingo. Complexity is vendor lock-in catnip
| astrobe_ wrote:
| Of course. If you were running an evil open-source company,
| you would favor "solutions" that generates demand for the
| services you sell (training, tech support contracts,...)
| while maintaining the belief that all this is necessary in
| "modern" IT.
|
| I think it's Rich Hickey who links in his one of his talks
| complexity with entanglement through etymology. This
| entanglement is sometimes also there to bind the customer.
| Although more often the "never attribute to malice..." rule
| is at work, as it's just easier, cheaper, etc... to let the
| complexity grow.
| antupis wrote:
| Yup sometimes it feels like AWS and Azure are like this.
| euroderf wrote:
| You make it sound like Scientology or some such. The analogy
| might be apt.
| valiant55 wrote:
| As a SQL Server DBA I couldn't possibly understand what you
| mean.
|
| (For simple cases it "just works" just don't look under the
| hood or try to do anything non-trivial and it'll be fine.)
| 2four2 wrote:
| In physical UI our group calls this the Microwave Problem. No one
| uses the 20 extra buttons on the microwave, they mostly just use
| one or two buttons. But no one will buy a microwave with few
| buttons.
| jeffreygoesto wrote:
| I must be no one. Love my Samsung ME82V since a decade now. Two
| dials. Period.
| closewith wrote:
| If you know the model of your microwave offhand, you're
| definitely an outlier!
| NortySpock wrote:
| "Dial-A-Yield: Not just for nuclear warheads!"
| euroderf wrote:
| I'm sure that having two dials costs more to produce than a
| crappy membrane keypad, and that the product manager was
| nearing retirement.
| diarrhea wrote:
| Hilarious coincidence. I had and loved that exact same model
| for the same reasons. Until one of the dials broke and I
| discovered how utterly irreparable the thing is. Had to get
| rid of it and indeed, it's impossible to find similarly
| simple models. Oh well!
| robocat wrote:
| I would love a microwave with a slider for power level and
| a dial for time.
|
| Best I have found so far is the now obsolete Breville
| BMO734 with jog dials for power and time, plus I use the
| quick-start and cancel buttons. Importantly you can change
| power and time even while it is running - very nice. Jog
| dials are not my favorite but the UI works. Extra feature
| buttons on inside door jam is a good design although
| honestly I never use the extra features. Ervery microwave
| with a keypad has been total shit UI in my experience.
|
| https://www.breville.com/content/dam/breville/us/assets/mic
| r...
|
| I bought a spare second hand one the other day for parts!
| mekoka wrote:
| I was confused for a moment as to which "no one" you were.
| The "no one" who uses the 20 buttons, or the "no one" who
| buys microwaves with few buttons.
| andruby wrote:
| same. love it. had to buy a microwave oven last year and went
| out of my way to find the same one.
|
| two dials is the only ui you need for a microwave.
| mattmaroon wrote:
| High-end blenders too. All I want is speed dial, pulse switch,
| and on/off switch. And that's all anyone wants, but for some
| reason every new generation has to have all these functions
| nobody uses.
| namaria wrote:
| No one has ever been paid for keeping a good design the same.
| bombcar wrote:
| Commercial ones are simple - unless it has a programmable "do
| the smoothie steps" button.
| mattmaroon wrote:
| I actually have gotten free Vita-Preps on occasion by doing
| events with the company. Most everything Vitamix has made
| for years has all sorts of that stuff. They thankfully
| still have a base line that is simple.
| thaumasiotes wrote:
| > All I want is speed dial, pulse switch, and on/off switch.
|
| Really? I want "quiet". A certain level of noise is
| inevitable, and blenders are way, way past that point.
| They're louder than food processors!
| wry_discontent wrote:
| You can buy that. That's what's on my VitaMix I bought a few
| years ago.
| drdaeman wrote:
| > But no one will buy a microwave with few buttons.
|
| Marketing is the king. Spend resources on memeing your way into
| people minds, then advertise "we removed the cruft to give you
| <something>" (more space, better experience, whatever you can
| think of, even if it's a big stretch) as some sort of
| revelatory breakthrough and bleeding edge innovation - and
| they're gonna buy it and joke about "uncool" others' microwaves
| with silly extra buttons are, affirming how cool their
| microwaves are.
|
| Worked for a lot of crap on the market.
| PurpleRamen wrote:
| There is value in choice. Not won't necessary always use just
| the same two buttons, so people like have the option to use
| other buttons. And quite often more buttons also come with
| better specs.
| blue1 wrote:
| Apple used to sell stuff that had "curated UIs": few control,
| few functions, and excellent UX. I remember the cleanliness of
| the iPod vs the overfeatured and complicated competitors.
| realusername wrote:
| The competitors were too cheap to have any feature, usually
| they had a big play button, a next and previous button and
| that's pretty much it.
|
| The settings were usually pretty poor on those mp3 players,
| on mine you had a microphone mode, language, timezone, some
| shuffle configuration and that's pretty much it.
|
| The iPod did look much much better and refined but in terms
| of simplicity, it's hard to beat the single play button of an
| mp3 player which doesn't know to do anything else. Those
| things were designed like appliance more than tech products.
| blue1 wrote:
| I don't think that'a true. Too many years have passed so I
| cannot cite makes and models, but I worked in an IT
| magazine back then and there were mp3 players with a lot of
| buttons, not unlike those overcomplicated VHS recorders
| which sold on "features".
| realusername wrote:
| That's true, those also existed but what I've seen, they
| were not bought as much as the cheap kind. The ipod gave
| a reason to pay extra, those half way though products
| really did not.
|
| I had one similar to those https://i.pinimg.com/originals
| /95/43/8b/95438b86a98370a741c2...
|
| Those things really didn't have a single real feature
| beyond playing music and recording with a microphone in
| the settings (which nobody really used)
|
| The screen and processing power was way too bad to do
| anything else anyways, even if they wanted to.
| aatd86 wrote:
| Alledgedly simple UI (although I never was a Apple guy, was
| using iRivers at that time), but building the iPod was hard,
| probably entailing a flew of difficult, complex hardware and
| design issues to tackle.
| lo0dot0 wrote:
| A lot of the competitors had less features, like not being
| able to select the next song without stopping the current
| song.
| antifa wrote:
| As someone who's owned several non-Apple mp3 players, I've
| never heard of this problem.
| makeitdouble wrote:
| iPod was useless without iTunes, and I wouldn't call iTunes a
| curated, excellent UX. We can't only look at the beautiful
| light and ignore the angler fish behind it.
|
| PS: if we include Sony's minidisk in the competion, the
| overall listening experience, especially the wired remote was
| just better. The digital walkman was still a better UX on the
| device side, except it has an even worse horrible PC
| experience and Sony barriers that made it a non starter.
| dimal wrote:
| Has anyone actually tried? I've searched for simple microwaves
| and can't find any.
| itronitron wrote:
| The IKEA MATALSKARE Microwave oven has 4 buttons, I press one
| to add 30 seconds and another one to cycle through the 4
| power settings. That is their mid-range microwave, it has 750
| watts of power and the more expensive models seem to have
| similar controls.
|
| Their low end microwave TILLREDA has two knobs, but I've
| never used it.
| youngtaff wrote:
| Our microwave has two knobs... one for the power setting and
| one for the time
|
| My only criticism of it is there's no button to cancel the
| time back to zero and you have to wind the timer knob back
| Zak wrote:
| What would be the advantage of a button to cancel instead
| of turning the knob back to zero? It seems like that would
| add quite a bit of complexity to the mechanism to provide a
| UI that's just different rather than obviously better.
| Zak wrote:
| This is also my preferred control scheme, and I bought one a
| few years ago.
|
| To see what's easy to find now, I typed "microwave oven
| knobs" into amazon.com and got several with the classic
| mechanical timer and power knob design. Most of those are
| relatively small, but "commercial microwave oven" found some
| larger ones.
| jayd16 wrote:
| It's a nice analogy but imagine trying to thaw something for
| 10s of minutes with the add 20 seconds button. That would be
| pretty annoying.
| iknowstuff wrote:
| A dial should do fine
| andy99 wrote:
| I've seen many one-button clocks that just either increment
| faster or change increment to a larger value if you hold.
| bmitc wrote:
| Popcorn even comes with instructions to _not_ use the popcorn
| button.
| xboxnolifes wrote:
| Only because popcorn manufacturers don't want the quality of
| their popcorn to be judged by the quality of your specific
| microwave's popcorn button implementation. They have no
| control over how it's implemented.
| bmitc wrote:
| Yea, I was emphasizing the point that most microwave
| buttons are unneeded.
| xboxnolifes wrote:
| But the button isn't bad. On most microwaves it probably
| even works well. Of course, if you rarely eat popcorn
| it's probably an unnecessary extra button.
| pdimitar wrote:
| That figures, my new microwave somehow thinks 90 seconds is
| perfect for popcorn while the one I am buying requires like
| 3m 30s.
| Sohcahtoa82 wrote:
| Technology Connections did a great video on the Popcorn
| button and why it sucks on most microwaves.
|
| https://youtu.be/Limpr1L8Pss
| swayvil wrote:
| Just got a new microwave. Panasonic NE 25 F.
|
| One dial.
|
| Built like a tank. Stainless steel. Compact yet roomy.
|
| And there's no stupid rotating platter.
|
| What they do is rotate the microwave antenna instead. But
| that's inside the guts somewhere so you never see it. (Why
| don't they do that on all microwaves? I dunno)
|
| So it's easy to clean. Even cooking. Max microwave.
|
| I love it
| loa_in_ wrote:
| So they do exist! It's a relief, honestly.
| acheron wrote:
| I searched that one up and it's on the "commercial" section
| of Panasonic's website with a price of "contact sales".
|
| How did you end up with it?
| swayvil wrote:
| Amazon
| mekoka wrote:
| And none of those 20 buttons can turn off the beep. So 2am
| sneak snacking means watching your oven like it's 1999.
| kayodelycaon wrote:
| Some microwaves do have this feature. I don't think you'll
| ever see it on the box so you won't know until you've read
| the entire manual.
| kibwen wrote:
| They can, actually! Your microwave probably has an arcane
| button combo that will turn off the beep. You'd never, ever
| stumble across it randomly, you need to read the manual. On
| mine, I need to hold the "2" button for five seconds.
| wry_discontent wrote:
| The real takeaway here is that you should read the manuals
| for all your appliances. I've learned a lot about them.
| tristor wrote:
| Honestly, I've had a number of microwaves in my life and I have
| read the manuals and attempted to use various other types of
| operation (such as sensor cooking). The reasons why I don't
| typically use those additional modes of operation are perfectly
| rational and not due to UI bias as such:
|
| 1. I know exactly how to cook something, based on time (and
| power level), because that's a mental model that's universal
| across microwaves.
|
| 2. I don't know how to cook something and need to follow
| package directions, which are always expressed as time (and
| power level).
|
| 3. I am iterating towards a desired end state, and want to do
| so in small step increments. The only possible way to do so is
| by short bursts of time (at a specified power level).
|
| These are the reasons I've never used any of the extra modes.
| Technology Connections did an entire hour long video about the
| popcorn button, and it sounds like at least /some/ microwaves
| actually implement a very good method, but most don't, and so
| these types of modes are also generally untrustworthy. Having
| additional modes has never been a deciding factor in buying a
| microwave for me, most of the time I bought am microwave based
| on materials, appearance, and mounting options.
|
| Now, a toaster oven, on the other hand, I want all the modes,
| and I use them.
| Ozzie_osman wrote:
| Complexity sells also because it obscures and overwhelms.
|
| "Mark me down, too, as an adversary of complexity, complexity
| that obfuscates and confuses, complexity that comes hand in hand
| with costs that serve its creators and marketers even as those
| costs thwart the remote possibility that a rare sound idea will
| serve those investors who own."
|
| This is John Bogle talking about finance, but I think it's more
| generally true.
| quantum_state wrote:
| This is one of the reasons that IT is in a state of ruin ...
| ngneer wrote:
| Yes. We feel this pain all the time in the realm of security.
| Main problem is the incentives are backwards. You would not pay
| your municipality to dump garbage on your lot, you pay them to
| take it away. And yet IT shops go for complex gadgets that end
| up being as vulnerable as the thing they are intended to
| protect (this has been the case forever, but if you need a
| recent example, Evil XDR was presented in Black Hat Asia'24).
| Ozzie_osman wrote:
| I worked at a certain FAANG company at a time where the promo
| process rewarded "solving complex problems". The more complex of
| a problem you could solve the higher your level (and your pay,
| your status, etc).
|
| Naturally, people were incentivized to find complex problems so
| they could solve them. Not only that, I think a lot of tech
| stacks at other companies evolved by copying this company's
| ideas, so even smaller companies with even less need for complex
| solutions ended up having them as well.
| AJRF wrote:
| Solving complex problems is worth promotion. Delivery complex
| solutions for the sake of them being complex is not.
| sratner wrote:
| Sometimes the promo committee can't tell the difference, i.e.
| was the problem complex to warrant the complex solution. They
| just see the effort put into solving it.
| bobsomers wrote:
| No, it's not. Identifying _which_ problems are worth solving
| (regardless of their complexity), and solving _those_ is
| worth promotion.
|
| Lots of engineers have a fascination with solving complex
| problems purely for the sake of solving them. When you make
| that your criteria for promotion you end up have to do many
| rounds of layoffs in harder times because you're staffed to
| the gills with people solving complex problems that deliver
| little to no actual value.
| ffsm8 wrote:
| Reality disagrees with your worldview. There is only one
| thing that's "worth a promotion" and that's convincing the
| person able to greenlight it that you deserve it.
|
| This very rarely corresponds with the ability to deliver
| good software in medium to large enterprises and entirely
| with your ability to market yourself. Which is easier if
| you're able to show them a super complex problem you've
| solved, because it sounds impressive to a mba...
| Retric wrote:
| You're assuming what results in a promotion is the same
| as what's worth a promotion. Nepotism makes it really
| easy to convince someone to promote you, but it doesn't
| mean someone else doing the same thing would get a
| promotion.
| ffsm8 wrote:
| What does nepotism have to do with that? Did you confuse
| it with something else?
| thfuran wrote:
| Did _you_ confuse it with something else? Giving someone
| a promotion for reasons other than the merit of their
| work is what nepotism is all about.
| ffsm8 wrote:
| $ define nepotism
|
| _the practice among those with power or influence of
| favouring relatives, friends, or associates, especially
| by giving them jobs._
|
| how is that related to someone finding a complicated but
| irrelevant problem to solve to show how competent they're
| to the mba thats in the position to greenlight the
| promotion...?
| Detrytus wrote:
| Well, an MBA that wants to promote their relative might
| need that "complicated but irrelevant problem" solved as
| a kind of "cover your ass" paper trail.
| lanstin wrote:
| It is very difficult for management to over time not
| change the rules on promotion enough that it tends
| towards a random walk where your level is approximately
| proportional to your length of service. Also,in at least
| the places I have worked, the enormous emphasis on
| individual performance both detracts from looking at
| group performance, i.e. actual productivity, and sucks up
| so much time. Copying from what execs have heard about
| Google they have promo boards, overly defined level
| descriptions, endless work of writing and rewriting promo
| packets, tactical discussions on which VPs need to be
| impressed independently of the merits or scope of a
| change, etc. There is a clear incentive to help people in
| a sister org over helping your team accomplish its goals.
|
| The whole system seems destined to be replaced by
| something more useful.
| latexr wrote:
| > Reality disagrees with your worldview. There is only
| one thing that's "worth a promotion" and that's
| convincing the person able to greenlight it that you
| deserve it.
|
| It seems pretty clear to me that the person you're
| replying to was talking in the sense of how things should
| be, not describing the way things are. Also, "worth
| promotion" is not their wording. You're nitpicking the
| wrong thing.
| vbezhenar wrote:
| Do engineers at FAANG choose what problems they want to
| solve? At places I worked, it was more of management task
| to choose problems to solve. Developers just worked on
| tasks they were given.
| ptmcc wrote:
| If all you do as a developer is just work on tasks given
| to you then you aren't going to rise very high in the
| ranks in any tech-forward company, FAANG or not. Sure you
| can make a decent career out churning tickets given to
| you by someone else, but you'll run into a glass ceiling
| pretty quickly. The tasks don't just appear out of thin
| air.
|
| A key part of being a senior+ engineer anywhere is the
| initiative and autonomy to identify problems, quantify
| costs and benefits, and work with management and
| stakeholders to come up with solutions that balance cost,
| complexity, schedule, and quality.
|
| Much of my work as a staff engineer is working with
| engineering, product, and business leaders to
| collectively identify what our biggest challenges are and
| how we should go about attacking them from the
| engineering side given all our resources and constraints.
| And then spearhead the implementation to get projects
| going the right direction and overseeing more junior team
| members.
|
| The actual coding is the "easy" part that comes after
| first defining the problems and specifying solutions and
| wrangling the competing needs of the business.
| Engineering should have a seat at that table since we're
| on the hook to build (and maintain) it, after all.
| brabel wrote:
| I agree with you up until the cliche "code is the easy
| part". People say this at the same time that they
| complain that people with 10 years of experience can't
| even solve FizzBuzz.
|
| The amount of badly architectured, buggy code I've seen
| in a couple of decades working with software tells me
| that "code is the easy part" is an absolute lie.
|
| Writing good code that's well tested and mostly just
| works, while being efficient, is such an extremely
| difficult task that I am not sure many developers in the
| world can do it. So, no, code is not the easy part, it's
| only the part where you can probably escape
| accountability (as no one will be able to tell) unless
| you have good devs in your team that can properly code
| review (which is also very rare).
| Aeolun wrote:
| I mean, code is both the hard and the easy part. I can
| write the code to get good code, or I can spend more
| effort on finding the right problems to solve and let
| others write shitty code.
|
| It hurts to let people do that, but ultimately shitty
| code still works, while having solved the wrong problem
| means that all the work goes down the drain.
| rob74 wrote:
| ?Por que no los dos? - find the right problems to solve
| _and_ write good code (or insist on good code being
| written) to fix them? Because bad code (unless it 's
| throwaway code) will quickly become a problem all of
| itself...
| stoperaticless wrote:
| Time is linited resource and it is hard to force to write
| good code, one has to be willing.
| ambicapter wrote:
| > code is not the easy part, it's only the part where you
| can probably escape accountability
|
| This is such a huge factor in how software is built in
| today's world.
| AJRF wrote:
| > Identifying which problems are worth solving (regardless
| of their complexity)
|
| I think you are completely wrong. Wouldn't the easy
| problems have been solved as they are by definition, easy?
|
| If there is economic incentive to solve a problem, and it's
| easy problem to solve then everyone can do it. That is not
| true of complex problems.
| fsloth wrote:
| I slightly disagree.
|
| There are lot of problems that are not identified as
| "easy" before someone tries to solve them.
|
| Hence, "identifying" step is often required to find the
| low hanging fruits.
|
| One catefory for these types of issues is "Complex root
| cause analysis, easy fix"
|
| So there might be a "medium severity" issue - something
| that is not business-lethal - and that appears hairy
| enough that everybody just avoids it. Then someone spends
| some time digging into it and finds it's some arbitrarily
| small change that fixes it.
|
| These things happen more often than not.
|
| The trick here is to look at the problem long and hard
| enough and realize a small change will fix it - instead
| of doing something completely tangential and complex to
| circumvent the problem.
|
| These problems fall into the class of "anyone could have
| fixed it" but only the person who fixed it actually did
| the hard work of figuring out the root cause.
| AJRF wrote:
| > One catefory for these types of issues is "Complex root
| cause analysis, easy fix"
|
| So...a complex problem then?
| rachofsunshine wrote:
| > Wouldn't the easy problems have been solved as they are
| by definition, easy?
|
| Only in an efficient market. And real world markets often
| have vast inefficiencies. The reasons they're inefficient
| don't always generalize, either. Companies can behave in
| certain ways because of personalities (2024 Twitter vs
| 2018 Twitter), embedded institutional norms (2024 Boeing
| vs 2020 Boeing vs 1980 Boeing), changing conditions (any
| 2024 startup vs any 2019 startup's finances), or a
| million others that don't necessarily spell doom for
| trying a different approach.
|
| One that's relevant a lot in the real world is market
| share. Large organizations very frequently get away
| without doing easy good things for long periods of time,
| which they can do because network effects and platform
| lock-in are powerful defenses against disruption. A lot
| of startups get founded on the idea "large incumbents are
| not doing this easy good thing, so let's do that and beat
| them". The fact that this ever works is a sign that
| incumbents must be leaving a _lot_ on the table, or their
| lock-in would never be overcome. The very existence of
| the startup scene is proof of the frequent inefficiency
| of markets in the short-to-medium-term (or at least of
| investors' belief in such).
|
| Even in cases where the incentives _are_ aligned and the
| market _is_ efficient, the world is often in non-
| equilibrium states. I like to think of incentive
| gradients as something akin to a (very complex)
| differential equation, and consider what _simple_ DEs can
| teach us about them. Consider, say, Newton's law of
| cooling: dT/dt = -k(T-T_e). Some calc 101 will tell you
| that solutions to this equation trend (exponentially! so
| not even slowly!) to a constant stable equilibrium T =
| T_e. But if you try to use that analysis on a fresh batch
| of french fries, you're going to get burned, because it
| turns out T(0) is very relevant to predicting T(1 minute)
| for realistic values of k.
| latexr wrote:
| > Wouldn't the easy problems have been solved as they are
| by definition, easy?
|
| No, not at all. "Easy" does not mean "obvious". I once
| replaced a call to _scp_ with a call to _rsync_ in a
| script I didn't originally write. The result was that an
| operation which used to take more than an hour and was
| thus run occasionally now took seconds and was executed
| every time. Both speed and reliability were increased
| with one simple and easy line change.
|
| While the bottleneck had been recognised earlier, the
| original authors had learned to live with it. They
| weren't aware of how it could have been improved so
| drastically with so little effort. That's another thing:
| easy is relative.
|
| Either way, you're conflating easy (the opposite of
| difficult) with simple (the opposite of complex, which is
| the word used by the person you're replying to). They are
| not the same thing. Easy mathematical formulas can make
| complex fractal shapes and complex programs can do simple
| things.
| aidenn0 wrote:
| Similarly I sped up a python script by 3 orders of
| magnitude by running a linter on it; the script
| _intended_ to cache a value for reuse, but neglected to
| actually reuse the value, resulting in an unused-variable
| warning in the linter.
| arp242 wrote:
| Solving problems that move the needle for the company in
| terms of customer experience, financials, or things like that
| are worth promotion. Sometimes these are complex problems.
| Sometimes not.
|
| Software isn't an art project; it's a practical tool to solve
| practical problems.
|
| Some of my more impactful changes haven't been all that
| complex; it was just a matter of knowing where and when to
| spend my time, based on working with our customer team, sales
| team, and directly talking to some customers.
|
| One of my more praised changes was adding a link to our
| support backend that saved our customer team minutes of
| manual work every time. This was literally just adding a
| permalink: 3 minutes of work. Simple and low-complexity? Yes.
| But also impactful and moved the needle, and no one else had
| done it in the previous years.
| MaKey wrote:
| > Software isn't an art project; it's a practical tool to
| solve practical problems.
|
| Yet me and my colleagues have seen code that resembles
| abstract art far too often - it's interesting to look at,
| but mind-bogglingly complex. Getting rid of that is a
| delicate balance act, as you risk stepping on the shoes of
| the people who wrote the code.
| arp242 wrote:
| Yes it's a problem; that's why I've started to use the
| "this isn't an art project" line, because some people
| really do seem to treat it as such.
| applied_heat wrote:
| I do see writing software like writing a book. I write it
| with the future reader in mind. It needs to be meant to
| be read.
|
| I picture my colleagues or young engineers 20 years from
| now combing through my programs, learning the problem
| domain, learning the tradeoffs we made at the time and
| why it made sense.
| test1235 wrote:
| with that analogy, I'd say code is more like the
| annotations of the manuscript before the reader sees the
| final print of the book
| datadrivenangel wrote:
| Which means you need to throw out half of the initial
| version and rewrite it!
| oytis wrote:
| I don't say it is necessarily a good metric for promotions, but
| solving complex problems is not the same as finding complex
| solutions
| stinkbutt wrote:
| finding complex solutions to complex problems is easy.
| finding simple solutions is whats hard.
| dimal wrote:
| I've seen teams destroy themselves by solving complex
| problems that didn't need to be solved. Instead of solving
| the real problems, they imagined a problem that was more
| interesting and complex, and tried to solve that.
| ranger_danger wrote:
| Do you have any specific (or similar to it) examples you
| could provide?
| shepherdjerred wrote:
| Years ago, my team at AWS considered writing our own
| declarative language to configure EC2 instances which
| would replace some old functionality within
| CloudFormation (cfn-init) until I pointed out you could
| achieve the same thing with our existing features (State
| Manager Ansible playbooks)
| euroderf wrote:
| Killjoy.
|
| (add smiley as appropriate)
| l0b0 wrote:
| These weren't fatal to the project or team, but did
| contribute extra work for net negative value (slower &
| more maintenance, with no relevant extra features):
|
| - Using Kubernetes to host an application when Docker
| Compose would do (specialist application with <10
| concurrent users).
|
| - Using DynamoDB to store a few kB of temporary data in a
| processing pipeline, despite having several existing
| PostgreSQL instances already and no DynamoDB ones.
| konschubert wrote:
| These are complex solutions, not complex problems,
| though.
| thaumasiotes wrote:
| They are solutions to complex problems. dimal
| specifically described the behavior of imagining a
| problem you don't have, and solving it.
| baobabKoodaa wrote:
| No, they are not solutions to complex problems. The
| problem "how to deploy an application for <10 concurrent
| users" is not a complex problem.
| thaumasiotes wrote:
| You don't really seem to understand the difference
| between "a problem you don't have" and "a problem you do
| have".
| brabel wrote:
| I worked on a team for a short while that decided to use
| Cassandra to store a few hundred thousand accounts,
| despite the data changing only slowly and being an exact
| match for a relational database. It was one of the worst
| choices I've ever seen in my career, and the only reason
| I could find was that people at the time wanted to learn
| Cassandra.
| Two9A wrote:
| Sounds somewhat familiar. I worked at a place that
| replaced a basic LAMP stack with microservices written in
| Perl and MongoDB as a backing store, for the sole purpose
| of raising complexity.
|
| And left Mongo on the default settings for the time
| (speed of return over reliability of saving data), so
| they ended up with a reporting replica which was MySQL.
|
| Don't think I've seen anything before or since which was
| architected so exactly backwards.
| Gibbon1 wrote:
| Think my company burned a year on a solution using
| Cassandra. I think the problem was 1/3 Cassandra and
| 2/3rds the people that would pick Cassandra amd Java over
| PostgreSQL and C# or go.
| beryilma wrote:
| For less than 10 concurrent users, I would rather say:
|
| - "Using Kubernetes to host an application when NodeJS
| would do..."
|
| I am not very knowledgeable about Kubernetes or Docker,
| but often times NodeJS+PM2 worked just fine for me for a
| small user base.
| rswskg wrote:
| or you know, a lambda. or fargate. Both much easier than
| worrying about pm2 or k8s.
| poslathian wrote:
| I once wasted several months of schedule and payroll
| wrestling to improve a DNN model - which resulted in that
| model getting much much better thanks to tons of creative
| and interesting work.
|
| We swapped the learned model for a perfect a oracle and
| realized the actual problem was elsewhere in the system
| and was easily fixed. None of those model enhancements
| were needed.
| ptero wrote:
| Not the person you asked, but working on remote sensing
| and perception I have seen (not once) the teams turning
| from improving use of available sensor data to things
| like cutting edge messaging technologies to support real-
| time data delivery from thousands of sensors (when they
| have three sensors today and might get another one next
| year and their current simple streaming will work just
| fine for up to 20).
|
| While those are interesting problems they have nothing to
| do with their current perception challenges (that _have_
| to be solved for a successful deployment), steal
| resources from the team and make life harder for a few
| remaining people actually working to solve current
| challenges, as they now need to switch to a more complex
| messaging and rewrite some of their existing utilities.
| nox101 wrote:
| in my defense I can think of at least four times I needed
| to prototype a complex solution to understand why it was
| the wrong solution and then discard it
| andruby wrote:
| +100. A lot of us love to over-engineer things because
| that's more fun to solve and looks good on a resume /
| evaluation.
|
| Kubernetes, (micro-)services, queues, nosql, lambda and
| other aws service are examples that I've seen in the wild.
| These can absolutely be valuable and cost-effective, if the
| problem needs that complexity.
|
| I love engineers that focus on the user, problem and
| business. They are soo valuable, especially for startups
| and smaller companies. Engineers that love solving complex
| problems without thinking much about the user are still
| awesome, if they can operate in an organisation where that
| critical thinking is done by others (product people or
| other engineers)
| paulddraper wrote:
| "Solve complex problems" < "Solve important problems"
| 7d7n wrote:
| The goal is to solve complex problems with as simple a solution
| as possible.
| jayd16 wrote:
| The goal is to provide user value. Complexity is falsely
| valued.
| lkdfjlkdfjlg wrote:
| Who says that's the goal? Providing user value is falsely
| valued.
| dijksterhuis wrote:
| Why do people need goals to do things? Having a goal is
| falsely valued.
| matanyall wrote:
| Why do people do things? Doing things is falsely valued.
|
| (Am partially sentient collection of coral, YMMV)
| datadrivenangel wrote:
| Why are things? Reality is falsely valued.
| weaksauce wrote:
| so that's how react was made
| hintymad wrote:
| This is a really tough problem to solve. If the company has
| amazing leaders, the leaders can correctly judge the depth of
| the problem and its impact, therefore rewarding the problem
| solver properly. Unfortunately promotion is really a tool for
| most leaders to advance their agenda. In a way Google invented
| this "solving complex problems" just to counter balance the
| misaligned incentives of the leaders, but to no avail.
| chii wrote:
| When the value generation is so far removed from the
| individual, the system will get skewed towards private taking
| over something more globally beneficial (globally as in for
| the entire company).
| hyperthesis wrote:
| oblig. perverse incentive
| https://www.folklore.org/Negative_2000_Lines_Of_Code.html
| itronitron wrote:
| Bonus points if you can describe it using mathematical
| terminology that few people have heard about.
| nasmorn wrote:
| At the Austrian Institute of Advanced studies there was a
| professor that got real good at stochastic differential
| equations and made a career out of applying them to anything
| and all in economics. One big advantage was that almost no
| other economist can actually follow it. Those few that can
| are obviously super invested in the technique
| greyw wrote:
| Stochastic differential equations is fundamental knowledge
| to do option pricing (black-scholes) among other things. I
| would expect an average guy educated in that field to be
| able to understand
| smokel wrote:
| In functional analysis, it is somewhat of a sport to
| attach indices to all four corners of a symbol. I
| remember overhearing a discussion between two big players
| in the field, and they obviously did not share the same
| starting point for reading the indices out loud. For
| sure, _I_ didn 't understand what they were talking
| about, but neither did they.
| r0ze-at-hn wrote:
| The wording might have changed, but the culture is 100% still
| there and is draining fighting against it.
| api wrote:
| Google? The place that gave us the current cloud native
| complexity trap?
| pphysch wrote:
| Google giveth K8s but also giveth Golang
| closeparen wrote:
| Similarly, when the promo process rewards impact and influence
| _on other engineers_ you get all the smart ambitious people
| making overengineered platforms, frameworks, and standards
| while no one competent or engaged is minding the actual end-
| user products.
| 3pm wrote:
| Not specifically about ML, but a good paper about unnecessary
| complexity introduced by a premature 'scalabilitization':
| The COST of a given platform for a given problem is the hardware
| configuration required before the platform outperforms a
| competent single-threaded implementation.
|
| Or "You can have a second computer once you've
| shown you know how to use the first one." -Paul Barham
|
| https://www.usenix.org/system/files/conference/hotos15/hotos...
| nickpeterson wrote:
| I highly recommend the Rich Hickey talk "Simple made Easy".
| Complexity doesn't sell well at all, but easy does. If a company
| can hire a bunch of people that know how to use 'foo' and the
| industry keeps talking about 'foo', they'll choose it even if foo
| is a complete boondoggle. See lambda architecture, most Apache
| projects, containers, etc
| contingencies wrote:
| https://www.youtube.com/watch?v=SxdOUGdseq4
| zeroCalories wrote:
| I think another aspect of complexity is that your customers,
| either internal or external, have a very specific idea of what
| they want, even if their idea is trash. So your product needs to
| be flexible(complex) enough to support all the use cases
| conceivable. Going to a customer and saying "trust us, do it this
| way" will make them lose interest fast.
| citizenkeen wrote:
| I work on a small internal ERP, and our new UX guy said "nobody
| needs all this info". And I said "agreed, nobody uses more than
| six columns. But the key stakeholders can only agree on 5."
|
| I think that's the key: nobody needs 20 buttons on a microwave,
| but some people love defrost or popcorn or whatever.
| scrlk wrote:
| Compared to other engineering disciplines, it seems like software
| is one that is most susceptible to veer towards complexity. Is it
| the ease of iteration? The relative youth of software
| engineering?
| Xeamek wrote:
| Relates to ease of iteration, but imo the biggest factor is no
| real responsibility when things breaks and how it is expected
| for software to break.
| dave4420 wrote:
| Relative lack of physical constraints?
| 01HNNWZ0MV43FF wrote:
| Bingo. Complex machines have more parts that wear out and
| need attention. Complex software, if it's well-written, can
| actually Just Work, and doesn't wear out.
| analog31 wrote:
| Investor optimism, peer pressure, and FOMO play roles.
| mro_name wrote:
| simplicity is the habit of zen, toaists, sufis and franciscans or
| the school of wirth - the mystics. Minorities each. It's just not
| appealing to the masses and the proponents don't really care
| about mass-recognition, either.
|
| But they go on nevertheless, stubborn as they are.
|
| Edit: Oh, and the razor Occam was a franciscan, too.
| vbezhenar wrote:
| IMO simplicity was what sold iPhones to the world. People love
| simplicity, but they need to be sure that they paid for quality
| simplicity. So simplicity must be accompanied by something that
| makes it look not cheap.
| kubanczyk wrote:
| Masses love _beauty_ and _status_. Simplicity is accidental
| in your example.
| AJRF wrote:
| I watch a YouTuber called Theo Browne sometimes. He is primarily
| a front end dev. When I watch him talk about his solutions to
| things I feel like i've been hit on the head with a baseball bat.
| The sheer number of _things_ that go into his demos is eye
| watering. The number of arcane terms about React he will mention
| in a single video astounds me.
|
| I don't mean to specifically call him out, but I worry that the
| complexity is what keeps him popular. And then you have someone
| like Pieter Levels just slinging raw php into production and not
| talking about anything like Suspense or Server Side Rendering or
| Hydration.
|
| They both get to the same ends (well Pieter Levels makes
| magnitudes of order more money I think) but there is a gulf in
| complexity. I'd actually argue something like Nomad List is much
| more feature rich than anything I see from Theo.
| thjdidiend wrote:
| I met Theo once. I didn't know who he was, but he made sure to
| tell me within the first few sentences that he was a very
| popular streamer/youtuber. I then watched him get recognized by
| someone else and they had a sort of friendly shouting match
| about something Theo has recently talked about in an
| opinionated way on his channel. His personality seemed
| perfectly suited for maximal media engagement through needless
| complexity. The more complicated things are the more arguments
| you can have and the smarter you can sound to those less
| familiar with all your esoteric choices.
| tonyhb wrote:
| I know Theo. He's a good person who wants to educate folks,
| and make things simpler.
|
| There are problems with education: you often have to make
| things contrived to show problems as fast as possible, and
| it's hard to convey all of the nuance. Theo, and others,
| definitely try to strike that balance and I think it's fair
| to say that this is because of how the front end world works
| rather than because of personalities.
| whstl wrote:
| I'm finding more and more that Youtube influencer software
| development is completely disconnected from real world software
| development.
|
| The amount of libraries and code for toy stuff is humongous
| compared to anything I see in production, and I've seen some
| monstrosities.
|
| I wonder for how long, though.
| vbezhenar wrote:
| My experience with frontend people is that they don't think
| twice about adding random libraries they just found that was
| released month ago. Also their projects are unmaintainable
| after one year, but they are long gone by that time and new
| developers arguing that they need to rewrite everything.
|
| I really hate small libraries and in my projects I tend to
| rewrite lots of trivial stuff, but that keeps me comfortable.
| antisthenes wrote:
| Looks like they found a way to unionize and achieve job
| security in a very roundabout sort of way.
| whstl wrote:
| Yeah, good point, for frontend, influencer code is
| definitely already leaking.
| soundnote wrote:
| DHH's plain JS, plain CSS obsession was right all along?
| whstl wrote:
| I wouldn't call it exactly right "all along", after years
| of him and the Rails team jumping bandwagons and having
| Prototype, Scriptaculous, jQuery, CoffeeScript, SASS,
| Sprockets with Babel, Webpack and then whatever is there
| now shipping as defaults in Rails, along with lots of
| other stuff.
|
| But he's been reasonable in the last couple years, sure.
| latexr wrote:
| > I'm finding more and more that Youtube influencer software
| development is completely disconnected from real world
| software development.
|
| You don't need the qualifiers. Influencers are disconnected
| from the real world, no matter the area. That's why they're
| "influencers", being a celebrity is the point. Think of it in
| contrast to someone you'd label a "maker" where the value of
| what they teach/build is much higher yet they have a
| comparatively much smaller (and usually geeky) audience.
| briantakita wrote:
| I have been hoping that isomorphic JS would take over PHP for a
| long time. Sadly these complexity gurus have been sucking the
| oxygen out of the room for over a decade now. I think it's the
| corporate "front end developers" who caused these problems.
| Almost like an envy of full stack or back end developers doing
| the "real engineering". Which drove the desire to have "real
| engineering" problems on the front end.
| rsync wrote:
| Hmmm ...
|
| I have been thinking about this recently in relation to the
| complex and unwieldy nature of modern car UI (especially in
| electric cars).
|
| It's so bad that it is _keeping me from buying a car that I
| need_.
|
| The conclusion that I have come to is:
|
| Sophisticated consumers are very different than _aspirational
| consumers_ - and there are always many, many more aspirational
| consumers.
|
| Therefore, catering to aspirational consumers at the expense of
| sophisticated ones is a rational economic choice.
|
| An aspirational consumer will put up with _all manner_ of
| deficiencies and gimmickry because they perceive them as being
| _emblematic of their consumer achievement_.
|
| In cruder terms:
|
| They are so happy to be driving a "luxury" car that they don't
| notice the garbage that came with it. Meanwhile, after decades of
| luxury car purchases, I just want the shifter to be intelligible
| ...
| iknowstuff wrote:
| It's kinda funny reading this as an owner of a Tesla. People
| who don't have them like yourself keep lamenting touchscreens
| online, whereas Tesla owners explicitly stay with the brand
| because of how excellent it is compared to other vehicles,
| touchscreen or not.
|
| Technology Connections just posted a video where he explains
| how he had to hold his car's ugly 90s era stalk for 4 seconds
| to change his wipers. Had to read a manual to discover that.
| This kind of crap is very standard in cars with disjoint
| components cobbled together.
|
| Meanwhile I get my live video sentry alerts on my phone, my car
| drives me to work, my gear selection is typically putting on a
| seatbelt and pressing the brake pedal as the car knows the
| right direction, everything important is contextually
| accessible via the wheels on the steering wheel instead of
| having 50 buttons for everything, and so on.
|
| It is simple and powerful. The problem with those luxury
| vehicles you mention is just awful execution.
| JackSlateur wrote:
| I'm working on a r&d team dedicated to finding ways to repair
| modern cars at scale
|
| As such, we get lots of car, mostly EV (but not only), up to
| 100kEUR/u
|
| The Telsas are indeed not the worst
|
| They are still boring af and not in the top of the basket
| AlexandrB wrote:
| As a Canadian driver, I'll take an ugly 90's era stalk over a
| touchscreen any day of the week.
|
| Teslas seem great if you live in California though.
| photonthug wrote:
| > my gear selection is typically putting on a seatbelt and
| pressing the brake pedal as the car knows the right direction
|
| What a hugely efficient time and energy saving innovation and
| only at the cost of lots of your money, personal safety, and
| basic human agency.
|
| Soon you can probably just hop in and without facing
| difficult decisions about where to go, get instantly taken to
| the biggest corporate partner or affiliate advertisers. Maybe
| robots there can invert you and shake you down so you don't
| even need to pull out the money
| SoftTalker wrote:
| Humans are good at adapting to the common operations of even
| the worst user interfaces and then they will stop thinking
| about how awkward they are.
|
| The iPhone is lauded as having a good UX. I think (even
| confining yourself to Apple's own apps) it's actually pretty
| inconsistent and a lot of things you "just have to know"
| because there are no cues that would lead you to discovery.
| But millions of people use them mindlessly because they have
| adapted to them.
| BLKNSLVR wrote:
| 1974 Celica is 'peak car' for mine.
| andruby wrote:
| > complex and unwieldy nature of modern car UI (especially in
| electric cars)
|
| Honestly, I love the UX and UI of a Tesla.
|
| It automates so many things that I find tedious in other cars:
| lock/unlock, close windows, pre-heat/cool, auto-set navigation
| to office in the morning and home in the evening, set seating
| and other adjustments for the driver based on which phone key
| was used. Navigation works thanks to the free connectivity (all
| other in-car gpses I've had to use were useless). Nice screen
| to select and play music. Voice command works reasonably well
| for selecting music.
|
| It's not perfect, but I prefer the UX & UI over all ICE cars
| I've driven before.
|
| As an example: my user journey when starting my drive to the
| office in the morning is a 2 step process: (1) open door and
| (2) put in drive.
|
| Especially in the winter that used to be 10+ steps for an ICE
| car: (1) find key (2) unlock car (3) open car (4) adjust seat
| because my wife drove before (5) press button to start engine
| (6) front-window defrost (7) rear window defrost (8) manually
| scrape the ice off the front window (9) select office in gps
| (10) release parking brake (11) clutch (12) put in gear.
| screamingninja wrote:
| While I agree with the sentiment that Tesla has wonderful
| UI/UX, your 10+ step EV-to-ICE comparison is disingenuous.
| Tesla does not scrape the ice by itself.
| andruby wrote:
| No it doesn't, but it doesn't have to. It warms up 20
| minutes before I get in, so there is no ice to scrape nor
| fogged window.
| bbminner wrote:
| If we are talking about paper reviews, what I am looking for in a
| paper as a reviewer is neither simplicity nor complexity. I am
| not even looking for "novelty". What I am looking for is a
| thorough and thought-provoking empirical analysis of a problem.
|
| I see plenty of submissions where 1) authors propose a system
| that is clearly a monstrosity Frankenstein patched together from
| a dozen of existing ideas - clearly a successful attempt at
| getting "bold numbers" using as many new shiny toys they could
| get their hands on without analyzing failure modes of either part
| in depth; 2) a simple modification of an existing method that
| accedentally improves the performance of the system but still
| lacks proper empirical or therotical justification of why this
| modification helps.
|
| While the second type of papers has at least some marginal value
| to the community or the reader, I still find such papers mostly
| useless. What brings value to the reader is a phd student who
| stared at the problem long enough to find quantitative and
| verifiable confirmations to his intuitions about the problem that
| lead to reproducible observations with predictive power. Ie "we
| experimentally verififed that indeed X affects Y exactly though
| the mechanism Z described in this paper in all cases, this helped
| us to improve metric A by B%, agreeing with Z". Not "we did X,
| and we saw A increase by B%", regardless of the complexity of A.
|
| Not all reviewers agree with me, sadly.
| IshKebab wrote:
| This is a very good analysis and doesn't fall into the trap most
| commentaries on stuff like this do: moaning about how something
| is bad without acknowledging any reasons for it, as if people are
| just arseholes. C.f. Electron, heavy websites, advertising, non-
| replaceable batteries, etc.
| Nevermark wrote:
| If only simplicity always meant easy to use. There would be no
| paradox if it did.
|
| One big problem is that for any product/feature not used in
| isolation in a very controlled context, simplicity is often
| suboptimal, inflexible and limiting.
|
| Complexity is often the result of building one thing that works
| well in a variety of situations, a lot of interoperable things or
| features to work (relatively) well together, or one thing with a
| lot of ways to interface with it. The worst case is all three -
| which is true for a lot of software.
|
| The result is a simpler purchasing choice, buy the most flexible
| product, but at the cost of far more product complexity than any
| particular user needs.
| euroderf wrote:
| And thus the emergence and rise of "opinionated software".
| astrobe_ wrote:
| > One big problem is that for any product/feature not used in
| isolation in a very controlled context, simplicity is often
| suboptimal, inflexible and limiting.
|
| "suboptimal" from the global perspective, because to me a
| simple solution should be a local optimum for a specific
| problem. For instance, one could argue that the Unix motto "do
| one thing well" generate lots of specialized programs that,
| even though they are an order of magnitude smaller than generic
| programs individually, together they take globally more space
| for same service level - a symptom of that is e.g. Busybox.
|
| For physical devices, the problem is probably more acute, or at
| least more visible.
|
| "inflexible and limiting" are terms I can agree on, that's
| generally how simplification works unless you have a genius
| idea. I don't see those words as absolute negatives, though,
| but rather as terms in a trade-off. If the software is open
| those issues can be mitigated sometimes by hacking; one
| advantage of starting from a simple (simplistic even),
| inflexible and limiting solution is that it's easier to evolve
| - that is to add the _necessary_ complexity.
| Nevermark wrote:
| > " suboptimal" from the global perspective, because to me a
| simple solution should be a local optimum for a specific
| problem.
|
| Except if that requires a company to create and support
| dozens of "optimal" versions of the same functionality for
| similar, but different performance impacting, circumstances.
|
| That is not globally simple for the producer, or for
| customers trying to figure out what version they need. Or
| having to manage multiple versions for different uses.
|
| > For instance, one could argue that the Unix motto "do one
| thing well" generate lots of specialized programs
|
| The clear design philosophy of Unix file and stream tools,
| and there interoperability, does enable much simpler command
| construction.
|
| But as a maker of tools, you can only leverage
| interoperability standards if they exist. For many software
| objects, and ways of combining them, standardized conventions
| are less well defined, less reliable, or non-existent.
|
| Thus ubiquitous glue code - navigating complex mismatches in
| information and conventions between components.
|
| Also note, that Unix scripting didn't eliminate C apps! The
| cost of Unix tool simplicity, is a massive loss of
| performance for many use cases. So similar functionality gets
| recreated over and over again, in virtually every C (or other
| language) app, to optimize for slightly different contexts.
|
| With work and standards, simplicity "islands" are achieved.
| But they form an archipelago - not a continent. Need to go in
| an unsupported direction and you have to swim a mile, instead
| of walk one.
| sesm wrote:
| Completely agree here. Complexity is the result of combining
| simple things together to optimally solve a specific problem
| under specific boundary conditions. The reason so many software
| devs are frustrated by complex artifacts, is that the initial
| problem and boundary conditions are usually not documented,
| often because some boundary conditions are actually a hidden
| agenda hostile to the recipient of the artifact.
| cs702 wrote:
| I've seen this firsthand:
|
| _> A common point raised by ML reviewers is that a method is too
| simple or is made of existing parts._
|
| And this is self-evidently true:
|
| _> ...simplicity is a strength, not a weakness. People are much
| more likely to adopt simple methods, and simple ones are also
| typically more interpretable and intuitive._
|
| It happens on a lot of different fields. For instance, a lot of
| investment management firms offer complicated investment
| strategies with high fees, even if a simpler strategy would do
| just as well. Quoting Warren Buffett:
|
| _> Investors should remember that their scorecard is not
| computed using Olympic-diving methods: Degree-of-difficulty doesn
| 't count. If you are right about a business whole value is
| largely dependent on a single key factor that is both easy to
| understand and enduring, the payoff is the same as if you had
| correctly analyzed an investment alternative characterized by
| many constantly shifting and complex variables._[a]
|
| ---
|
| [a] http://www.berkshirehathaway.com/letters/1994.html
| rglover wrote:
| I built a full-stack JS framework [1] that I thought would be a
| hit. As best as I can tell, because it lacks the complexity/word
| salad of existing solutions, it's mostly been ignored despite
| being (imo) an elegant solution to a long-standing problem.
|
| [1] https://cheatcode.co/joystick
| j45 wrote:
| This is an inviting read, and I think would resonate with many.
| I avoid javascript for the brittle timesuck it can become
| maintianing the past while shaking one's fist at other legacy
| systems. I've never known this to be a problem because I avoid
| systems that do this to my time, unless it's absolutely
| unavoidable. It makes me much more productive to use tools that
| work, and continue to work, so I spend more time with problems
| than rolling a temple to my own veneration. It might work for
| others, and it doesn't make it right, it might not work for me,
| and that doesn't make it wrong.
|
| It's OK not to be for everyone, but your people will find
| whoever you are being.
|
| Maybe try it as the content for your landing page. Lots of one
| liners that resonate.
| rglover wrote:
| Thanks for the feedback/tips, I'll give it a shot.
| j45 wrote:
| My comment was in relation to the philosophy page of your
| framework. I thought I had included it.
|
| https://docs.cheatcode.co/joystick/philosophy
|
| I hope you do, I'm sure there would be at least an audience
| of 1000 true fans for this.
|
| Its one of the only javascript frameworks that stood out to
| me because of that page having a real enough human story.
|
| Feels similar to the individual developer starting a
| project wondering if any framework is looking out for them
| to stay productive :)
|
| I generally avoid the javascript brittle maintenance time-
| sinks but using it is a reality and knowing that there's
| simple frameworks that can absorb and handle complexity are
| valid.
| degurechaff wrote:
| I think not using common license like GPL, BSD or MIT make
| people think twice before even trying the framework.
| rglover wrote:
| The license is pretty straightforward and fills in the gaps
| where the others fail to protect OSS creators (leading to
| headaches like w/ Redis). Perhaps it's too idealistic to
| think people will just read it and see if it matches their
| needs?
| golergka wrote:
| I'm not a lawyer, so I'm not risking my company's legal
| liability with my ability to comprehend a legal document.
| rglover wrote:
| Assuming the project/tool was interesting and that was a
| concern, why not just forward it to your legal department
| (or manager) to get clarification on if it's an option?
| tirpen wrote:
| And then you have to wait a month and more and they log
| time on your project budget. Legal department takes that
| kind of stuff seriously and don't give off the cuff
| opinions. So now your project is severely delayed you are
| under budget and the only thing you got from it is that
| you _maybe_ gets permission to use a new library.
|
| Ooooor... you can just pick one of hundreds of options
| with a more commonly used licenses that have already been
| approved by them many years ago.
| photonthug wrote:
| This is not realistic. You're asking new users to go out
| on a limb to even figure out if they can work with your
| stuff. the casual "hey send an email to legal" suggestion
| just cost your potential collaborators weeks of time and
| thousands of dollars before they can even evaluate the
| product itself
| golergka wrote:
| Because another similar project uses a standard license
| and doesn't require this sort of friction.
| rglover wrote:
| It's a stretch to call it a legal document (technically,
| yes, but it's written so that anyone can understand it).
| I wrote it myself in plain english [1].
|
| [1] https://saucr.org/example
| kragen wrote:
| no, i've already spent the necessary hours of debating to
| what extent the agpl3 is compatible with cc-by-sa 4, i
| don't want to invest those hours again in a license that's
| used by only one project and, if history is any guide,
| probably contains important mistakes in how it's written
| and will need to be redrafted after those mistakes are
| noticed. i don't have a legal department
| sesm wrote:
| What's the long-standing problem and what's the idea behind an
| elegant solution?
| kouru225 wrote:
| In professional settings, people care only about complexity.
|
| In the informal media world, people care only about simplicity.
| The most simple narrative wins out every time.
|
| We're in a world of extremes.
| 1vuio0pswjnm7 wrote:
| Software developers may embrace complexity for the purpose of
| commercial benefit and suffer all its disadvantages, not to
| mention passing on those disadvantages to users.
|
| However non-commercial users, hobbyist programmers, who derive no
| commercial benefit from complexity are free to reject it and its
| disadvantages.
|
| For example, I choose on a daily basis to use simpler,
| noncommercial software that I compile myself. The use of such
| software is routinely dismissed, discouraged and even attacked by
| many software developers commenting on HN. Certainly, its use in
| place of more complex alternatives does not benefit their
| interests. It does benefit mine. I like (relative) simplicity.
|
| Each is free to do as they please. If one prefers complexity, as
| many do, then there is no shortage of alternatives to choose
| from. Complexity is booming.
| pornel wrote:
| I find such laments annoying, because they're full of obvious
| platitudes. It's easy to sound smart quoting Einstein and
| Dijkstra. It's cheap to make generalizations, and point fingers
| at complex solutions when having both the benefit of hindsight,
| and ignorance about their true requirements.
|
| _" as simple as possible, but not simpler"_ is always right.
| Messy solution? You should have made it simpler. Primitive
| solution causing problems? You weren't supposed to make it too
| simple. Why didn't you think about making it just perfect?
|
| In reality, it's very hard to even get people to agree what _is_
| simple, when solutions have various trade-offs. Maybe it is
| easier to focus on maintaining one complex database, than to have
| 3 "simple" ones, and triple admin work, and eventually end up
| having to sync them or implement distributed transactions.
|
| Something simple to implement now may cause complex problems
| later. A simple off-the-shelf solution that doesn't fully solve
| the problem will breed complex workarounds for the unsupported
| cases, and eventually add complexity of migrating to something
| adequate. If you didn't correctly predict how a solution will fit
| all your requirements, you should have simply listened to
| Einstein.
|
| All the advice to "just" do something "simple" is blissfully
| unaware that these solutions are not panacea, and it's rarely a
| plain choice between complex vs simple. Projects have constraints
| - they may need to work with existing messy systems, inconsistent
| legal requirements, or changing business requirements. They may
| prioritize time to market, or skills they can hire for. And
| there's brutal economics: maybe annual report export is a Rube-
| Goldberg machine, but it's done once a year, and a rewrite
| wouldn't pay for itself in 50 years.
|
| The discussion about complexity rarely acknowledges that projects
| and their requirements grow, so something perfectly simple now
| may become complex later, in a perfectly rational way, not due to
| incompetence or malice. Storing data in a plain text file may be
| beautifully simple in the beginning, and become a bad NIH
| database later. But starting with a database for 3 rows of data
| would be overcomplicating things too. And there's cost to
| refactoring, so always using the ideal solution is not that
| simple either.
| carl_sandland wrote:
| Some complexity is inherent to the problem, but most seems to
| be incidentally introduced by the realities of deployment (non-
| functional), configuration (functional) and chaos monkeys
| (users). There is a particular 'breed' of incidental complexity
| I see with space cadets and front end developers for sure.
| Complexity is complex lol.
| pdimitar wrote:
| You and I would think the platitudes are obvious but I've been
| at tables with people where stating those made people blink
| with that unnamed dread that hits you when you realize you
| haven't understood something super simple for a very long time
| and are just now getting it for the first time. That
| happened... a number of times in my life and career.
|
| Truth is, much less things are as obvious as you and I think.
|
| > _" as simple as possible, but not simpler" is always right.
| Messy solution? You should have made it simpler. Primitive
| solution causing problems? You weren't supposed to make it too
| simple. Why didn't you think about making it just perfect?_
|
| Nah, that's obviously (heh) a non-sequitur; iteration always
| beats planning. We know it by practice.
|
| > _In reality, it 's very hard to even get people to agree what
| is simple, when solutions have various trade-offs._
|
| That's why you don't ask for permission, you ask for
| forgiveness. :) Another law of our profession, if not in many
| others too.
| pornel wrote:
| > That's why you don't ask for permission
|
| I didn't mean agreement as permission, but as having the same
| judgement. One person may say bash is the simplest, another
| that Makefile is even better, and third person will say
| they'll both become a mess, and it's simplest to use Python
| from the start, and so on.
|
| Reasonable people may disagree where is the line of "but not
| simpler". Something that is "simple" to one person, is
| "primitive" to another.
|
| If someone says they have a simple and elegant solution, but
| it requires their skills, is it really simpler than a "dumb"
| solution that more people can understand? (e.g. DB vs Excel?
| C vs JS?).
|
| Everyone may be in agreement that things should be super
| simple, but there may be a choice between simplifying
| implementation vs simplifying operations. Or people may
| disagree about future requirements and argue that a solution
| that is the simplest now will hit a complex scaling problem
| later, and the total-lifetime-complexity of the product will
| be minimized by another solution instead.
| sesm wrote:
| > ignorance about their true requirements.
|
| But why the true requirements are hidden?
| dang wrote:
| Discussed (a bit) at the time:
|
| _Simplicity Is an Advantage but Sadly Complexity Sells Better_ -
| https://news.ycombinator.com/item?id=32491079 - Aug 2022 (6
| comments)
| hyperthesis wrote:
| The solution to a problem can be simple.
|
| But now we want other things. e.g. car=transport, then: speed,
| efficiency, style, non-polluting, safety, price, a/c,
| touchscreens, self-driving etc.
|
| The boundless complexity of human desire.
| hyperthesis wrote:
| "There's no bragging rights to your software, because it's too
| simple to use", a developer criticized my product. This reduced
| its viral spread, though managers liked it.
| hyperthesis wrote:
| Complexity signals innovation: an invention that is merely a
| "workshop improvement" won't get patented. Complexity signals
| non-obviousness.
|
| Too easy -> easily copied -> and no long-term competitive
| advantgage. Complexity signals hard.
| marcus_holmes wrote:
| Agree with everything said in TFA.
|
| Except maybe toning down the exhortation to use other people's
| code so much. I totally agree that using existing solutions is
| very often the simplest solution; I would not want to rewrite
| PostgreSQL or any crypto libs. But too many dependencies can get
| messy; there is definitely a line at which writing your own code
| specifically for this situation is simpler and better than
| importing a more generic dependency that is much larger and more
| complex than it needs to be for your use case (because it covers
| more than just your use case). Or, (e.g. Left Pad), where the
| dependency is not actually easier than just writing the code
| yourself. Importing any dependency carries with it some
| complexity because it means integrating someone else's code into
| your own, with the ensuing security implications and version
| problems. It is not always more complex to write your own code.
|
| My general rule of thumb is that if it'll be quicker for me to
| code a solution to this specific problem than it would be to
| learn the API for an import and integrate it, then I'll write the
| code myself.
| hooby wrote:
| Over some decades of doing development work on legacy systems -
| sometimes by my companies own design, sometimes contract work for
| a customer - I've seen lots of things that make me believe that
| certain customers do prefer complex, buggy software for a very
| specific reason:
|
| They can hide behind it. "I couldn't finish the task on time
| because the software had a bug" - sort of stuff. "I couldn't do X
| because the software doesn't support Y", "The dog ate my
| homework", etc.
|
| In many cases, it would have been quite possible to design
| simple, easy and far less bug-prone solutions - but then people
| working with the software would no longer be able to hide that
| certain failures might be due to their own incompetence, rather
| than being a software issue. Therefore - especially in companies
| with high top-down pressure - people actually prefer working with
| software that their managers don't fully understand, and that's
| known for having some bugs and problems.
| pdimitar wrote:
| > _They can hide behind it. "I couldn't finish the task on time
| because the software had a bug" - sort of stuff. "I couldn't do
| X because the software doesn't support Y", "The dog ate my
| homework", etc._
|
| I was quite naive most of my career (and life, come to think of
| it). Back when I changed my first job where I spent 5 years,
| and was 27 at the time, I replaced one super-complex GUI
| program with a small GUI wrapper around 2 CLI programs. The
| thing worked EVERY TIME even with faulty input and on the rare
| occasion it did not work it gave informative error messages.
|
| The 3 women working with it HATED my guts for it. Took me
| probably a year after I left to finally understand why. Yeah, I
| was not very bright back then.
|
| And with time I started to think that people want e.g.
| Microsoft Teams because they can wipe their arse with it when
| the need calls for it.
| smetj wrote:
| This x 10
| tipiirai wrote:
| > Simplicity is an advantage but complexity sells better
|
| Exactly my feeling with TypeScript
| spixy wrote:
| except JavaScript is not an advantage at all
| boxed wrote:
| My dad sold software for electron crystallography. You could buy
| the software and 4 electron microscopes and fund a team of
| doctoral students for the same price as one big fancy electron
| microscope that did the same thing in hardware. He could not
| compete.
| Puts wrote:
| I had this history teacher in high school giving the class an
| assignment to write an essay on the events leading up to the
| Second World War. The first question that came up was how long
| does this essay need to be - to which the teacher replied that if
| you can cover this complex topic on one single A4 that would give
| you full score on the assignment - but that he sincerely doubted
| that anyone could cover such a complex topic in such a short
| amount of text. Everyone was mind blown by this argumentation.
| Nobody had ever heard a teacher say anything like that and that
| kind of shows how we already as kids are thought that more is
| always better.
| javajosh wrote:
| It's a good anecdote but needs a bit more boundary condition.
| One can always pick a level of abstraction to make an
| explanation long or short; humans usually pick this level based
| on context and social convention. For example, if the question
| was "describe how a keypress results in a screen glyph" can be
| described in one sentence, or in a long series of books
| (assuming you get into the firmware, software stack,
| electronics and materials science, manufacturing processes,
| etc). For WW2 you could say it started when Hitler invaded
| Poland, and then France. Or you could get into the Versailles
| treaty. Or you could talk about the evolution of life on Earth.
| You might say the latter is pedantic, and it is, but it's also
| technically an event that led to WW2.
| BLKNSLVR wrote:
| At my current place of work complexity signals minimum viable
| product stacked upon minimal viable product stacked upon minimum
| viable product.
|
| Function additions as patches upon a platform that started life
| as an MVP but was never properly even planned out nevermind built
| out, and then suddenly demand for new features arrive with
| dollars attached and the baselines are tossed out with the bath
| water.
| kroolik wrote:
| As I started to think for some time now: you can have a challenge
| or a solution.
|
| As engineers, we are often tempted to challenge ourselves,
| straying away from the latter. There is less perceived pride from
| following simple solutions.
| atomicbeanie wrote:
| Complex solutions are easy. Simple is hard. Often simplicity
| takes time, iteration and understanding that comes from actually
| operating a system. I think the missing link here is the Kaizen-
| oriented refinement that turns complex into simple over time. I
| find that modern OO-languages frustrate this process by needing
| cross-cutting changes to refactor for incremental improvements.
| Expression-oriented languages (like Clojure) are much more fluid,
| enabling the incremental refactoring required to transform the
| initially complex and awkward system into the simple and refined
| scalable system. Unfortunately, just like other languages, it is
| possible to write difficult-to-change systems in Clojure. And
| that seems to be often the way it is done.
| harperlee wrote:
| Specifically for clojure, do you have any recommendations about
| how to make systems easy to refactor? I've often read
| discussions about how dynamic languages are quicker to write
| and more difficult to refactor than static ones, and I've had
| my fair share of dealing with issues during refactoring of
| clojure code, but I don't remember having read anything
| particular around clojure best practices. Googling for a bit
| does not produce particularly insightful results, so if you
| have any insights that'd be awesome.
|
| EDIT: Part of the things I'm finding are my own comments in HN
| from some years back, in fact :(
| atomicbeanie wrote:
| Yes, I like to call the style Procedural Composition. The key
| characteristics are no logic with IO, and all system
| functions are assembled from higher-order middleware
| functions. This is the way ring, the web framework, and
| various client libraries like clj-http work. One of the best
| ways to get familiar with it is to look at the ring
| libraries.
|
| What this allows one to do is assemble handlers from lots of
| small higher order functions. It has the downside of one
| needing to have initialization well organized and thought
| out. But the fractal-cul-sac as one co-worker has nicknamed
| it of ever dividing and increasingly specialized functions
| with IO and logic twisted together is effectively prevented.
| One can always modify one handler without affecting others or
| changing how existing functionality works. And it is always
| testable in small unit tests because the logic is pure.
|
| Systems built in this style can radically reform themselves
| in a controllable, reliable and consistent way indefinitely.
| They are immune to the "apogee" phenomena whereby a system
| gets to the size and fragility where it can no longer be
| modified without causing unforeseen regressions, triggering
| the need to rewrite it to move it forward.
|
| This style is for handler-oriented procedural software common
| in web services etc. It does not apply to embedded state-
| machine oriented software that operates real-time control
| etc. That is a different problem space.
| hammock wrote:
| I saw a 2x2 matrix recently that showed how NP-hard problems
| require exponential time to solve but polynomial time to verify
| the solution. It gave examples for every other cell of the
| matrix besides (exponential time to solve, exponential time to
| verify), which it left as blank or N/A.
|
| I think we have found something that fits that square: truly
| simple solutions. It's easy to come up with a simple solution
| that is unsatisfactory, that's not what I'm talking about.
|
| I mean a solution that is so simple and complete, that it was
| HARD to come up with. It's easy to verify that such a solution
| is simple, sure, but it is HARD to verify that the solution is
| truly complete or satisfactory
| kibwen wrote:
| _> It gave examples for every other cell of the matrix
| besides (exponential time to solve, exponential time to
| verify), which it left as blank or N /A._
|
| I would be interested in seeing this matrix, because it
| sounds incomplete to me.
|
| Any NP-complete problem, as in a problem that is exponential
| to solve but polynomial to verify, is a "decision problem"
| version of a "optimization problem" that is exponential to
| both solve and verify.
|
| For example, the decision-problem version of the traveling
| salesman is, "given a graph of nodes and weighted edges, does
| there exist a route that visits all nodes with a total edge
| cost of less than _N_? " Solutions are hard to compute
| (evaluate many paths to find a good solution) but easy to
| verify (evaluate the given path exactly once and compare the
| cost to _N_ ).
|
| Meanwhile, the optimization-problem version of the traveling
| salesman is "given a graph of nodes and weighted edges, what
| is the route that visits all edges with the least cost?" The
| solution is now both hard to compute and hard to verify,
| because to verify it you also need to consider the entire
| decision space to determine whether or not there's a route
| with a lesser cost.
| javajosh wrote:
| The reason it's hard to refactor to simplicity is that one must
| feel free to modify foundational assumptions, and the
| repercussions of that change are both hard to implement (you
| must recapitulate all following changes with the new
| assumption) and test. By "foundational assumption" I mean
| architecture at the high level, and general code organization
| at the lower level. It is the "second system" problem, writ
| small but many times over.
|
| Given that code grows over time in accordance with selection
| pressure, these lateral, foundational changes are _always_
| going to be difficult because recapitulating the following
| growth in general takes the same amount of time as the original
| system took to grow. The irony is that if that system is making
| money, it is even LESS likely that the will to simplify it will
| arise; if the system doesn 't make money, then there will be
| neither will nor resources to try it.
|
| "Physics progresses one funeral at a time", Planck's Principle
| [1], applies here. Software gets simpler but not laterally
| within a working project; it only gets simpler with new
| projects. Luckily software devs seem more open-minded than
| physicists so we can progress faster than funerals, but not
| arbitrarily so.
|
| 1 - https://en.wikipedia.org/wiki/Planck%27s_principle
| wry_discontent wrote:
| Changing and refining Clojure code is a remarkably pleasant
| experience. There's very little state, so you can usually just
| grab what sexp you need and extract it.
| sesm wrote:
| I'm always surprised at how much people can talk about simplicity
| and complexity without giving any definition of those terms.
|
| Basically, the actual content of this article is giving the
| author's own indirect definition of the word 'complex'. The way I
| understood the definition is 'complex = overgeneralised and
| purposefully made harder to understand'.
|
| This is different from other definitions. For example, according
| to Rich Hickey's definition, multimethods are 'simple' because
| they provide 'polymorphism a-la carte'. According to author's
| definition they would be complex because they are an
| overgeneralised implementation of polymorphism.
| smgit wrote:
| It doesn't really matter. There might be a "simple" or a
| "complex" solution to a problem, but there is no guarantee
| whoever is given the problem, has the time, or cash, or tools,
| or skill, or info, or team, etc etc to do the job right. And
| thanks to history we know quite well, very few like to admit
| shortcomings and limitations, so endless misunderstandings are
| the result.
|
| Quoting Herbert Simon - "You can satisfice either by finding
| optimum solutions for a simplified world, or by finding
| satisfactory solutions for a more realistic world. Neither
| approach, in general, dominates the other, and both have
| continued to co-exist in the world"
| briantakita wrote:
| Complexity is like a Ponzi Scheme. Ponzi Schemes are effective
| with sales. Midwits love Complexity & love Ponzi Schemes. Midwits
| drive the markets due to their population being large.
| wccrawford wrote:
| The simple solution is superior if it does _everything you need_.
| If it doesn 't, the complex solution suddenly becomes a lot more
| desirable.
| sebastianconcpt wrote:
| Complexity isn't evil, but hiding in it some secondary interest
| of who sold that complexity likely is (because of Murphy's Law
| applied to human psychology?).
|
| Also it has a protective corollary: the interested parts in
| preserving complexity because injecting lets say a much needed
| and correct new simpler alternative would either reveal the
| aforementioned dubious interests or reduce the incumbent's
| authority (power), hence, all the incentives are set to boycott a
| system improvement from the top.
| sebastianconcpt wrote:
| Which techniques have you developed to deal with this problem?
| renonce wrote:
| This has been my single major frustration with academia. Papers
| are getting long and complex (and very often unnecessarily so)
| and reviewers like rejecting with "not innovative" or "too little
| work".
|
| I mean there is a great amount of actual work where the
| complexity is inevitable, say homomorphic encryption or zero-
| knowledge proofs, but they are based on solid foundations,
| starting with the definition of group theory with just four
| axioms and building up and so on, where every definition is
| either simple or has lots of uses elsewhere. In contrast, in
| machine learning and operating systems research, people just seem
| to like to build algorithms from scratch and make it look
| incredibly complex (whether it actually is complex) and that just
| makes my life harder just to read the paper. It's getting close
| to the point where reading the paper takes more cognitive load
| than conducting the research myself (having to understand 100s of
| papers to find the one that's useful for my case). When it does,
| what would be the point of publishing it?
|
| I recognize there is a lot of useful work in academia but it's
| really hard to enjoy doing it when the results you would be most
| proud of is not likely to be well recognized.
| _gabe_ wrote:
| It's funny that you mention this. The most helpful research
| papers I've read have been written by private companies. Here's
| a couple off the top of my head[0][1]. Short and straight to
| the point.
|
| [0]:
| https://steamcdn-a.akamaihd.net/apps/valve/2007/SIGGRAPH2007...
|
| [1]:
| https://developer.download.nvidia.com/devzone/devcenter/game...
___________________________________________________________________
(page generated 2024-05-06 23:02 UTC)