[HN Gopher] Beware the Complexity Merchants
___________________________________________________________________
Beware the Complexity Merchants
Author : kiyanwang
Score : 34 points
Date : 2025-05-25 19:25 UTC (3 hours ago)
(HTM) web link (chrlschn.dev)
(TXT) w3m dump (chrlschn.dev)
| stego-tech wrote:
| This isn't just applicable to code or development; there's a huge
| B2B marketplace built on the idea that the more complex your
| business is, the more profitable it will be. Hence why every
| business must be harvesting as much data as possible, analyzing
| it with different tools, across different platforms, different
| storage methods, different transformation and retrieval tooling,
| different vendors and formats and product suites and
| integrations.
|
| It drives leadership nuts, but I find asking the "why" or "what
| problem does this solve" questions helps the organization remain
| focused on what actually delivers value versus what's just hype
| we can ignore or throw away.
| jmugan wrote:
| I think about this from the angle of administrative burden. Sure,
| the tax code might be better if you make a tweak for zucchini
| farmers, but now you have to ask every taxpayer whether they have
| engaged in that activity.
| userbinator wrote:
| I suspect a lot of accidental complexity also comes from those
| who don't really know what they're doing, so instead of focusing
| on the result, they take a very roundabout path until they
| stumble upon a solution. AI and "vibe coding" is going to make
| that problem much worse.
|
| For an interesting example of the outcome of _strongly_
| optimising for essential complexity, look at the demoscene. They
| have done some amazing things that were thought to be impossible.
| patapong wrote:
| Interesting. I also think a lot of complexity stems from
| developers preferring building systems over building products.
| It is much more satisfying to build somehting that can address
| many use-cases, even if we are only working on a single use-
| case. But, this also introduces the cost of complexity as the
| user/downstream developer is pushed into making the choice of
| which of the many available paths they want to take.
|
| See the eternal urge of gamedevs to build engines instead of
| building the game.
| brookst wrote:
| Yep -- and it's hard to argue against. Option value is
| valuable. Is it worth spending 20% more and de-optimizing for
| the core use case to support unknown future use cases? I'm
| not sure there's a general purpose answer.
|
| And if you do stick to purpose-specific design and management
| asks for a seemingly minor expansion of scope, the "this is a
| small change, why did we make the system so rigid that it's
| expensive to update?" is an uncomfortable conversation.
| pan69 wrote:
| Experienced developers understand the start-up cost
| associated with building a software product. So, when
| developers think ahead and architect and design their
| software for a possible future roadmap and that roadmap
| doesn't eventuate, they have introduced accidental complexity
| and they are considered idiots.
| eddythompson80 wrote:
| I agree with the general sentiment. The article is vague on the
| specifics as to what counts as "added complexity" though, which I
| found to be the central issue.
|
| Everyone loves a bit of abstraction that encapsulates a given
| complexity and make it a single simple concept. This is not: "a
| complex bit of technology that has pros and cons and will lock
| you in a particular architecture and vendor and would almost
| always necessitate 2 architectures because not all
| tasks/scenarios would be suitable for it". It is a "Lambda". So
| simple. Just a `handle(event) {}`, how much simpler can this be?
| No complex runtimes, VMs, environments, etc. It's just a
| `handle(event) {}` no complexity to see here. _good luck_.
|
| On the other hand, sometimes people who "champion" simplicity are
| also the same people who don't care about the engineering part of
| it. The "Hey, I added a full text search. It's implemented as a:
| select * from posts where column1::text like $1
| or column2::text like $1 ... or
| columnN::text like $1
|
| Lets push it. Oh out database CPU is burning, search is so slow.
| What a surprise this is. I guess it validates the popularity of
| search. Can we optimize it? Maybe we cache the result? Maybe we
| add an LLM to normalize queries so we can cache results more
| effectively? I'm trying to keep things simple"
|
| There is also the requirement or ask that is trying to hide a
| particular complexity from one side by shoving it all under a rug
| somewhere. Once the complexity has been sufficiently shoved under
| the rug, we can think of the rug as just a rug. We can move it
| around and use it like a rug. Surely the shit underneath will
| never have any impact on anyone any time.
| aleksiy123 wrote:
| I feel like all these articles have this issues.
|
| The hard part is in knowing which is which and I don't think
| anyone real has a tried and true solution for it.
|
| I think because its really about correctly predicting the
| future in a n continually evolving environment.
|
| Those "simple" solutions can be piled on top of each other turn
| into an absolute monstrosity over time.
|
| And then engineered solution can be overengineered and overly
| complex when it turns out the problems it solves never ended up
| happening.
|
| On top of that people don't even think of simplicity in the
| same way. One person's simple is another's overly complex.
|
| What seems to work for me is try give yourself outs/alternative
| paths.
|
| Hedge your bets by overengineering slightly on where you think
| there is more risk. And keep it simple where there is less
| risk. Then reevaluate.
| ashayh wrote:
| Complexity is also about empire building and job security.
|
| If every dev took the path of least resistance, and did the
| easiest thing that did its task, we would lose 80% of all tech
| jobs. This would only funnel more money to billionaires and share
| holders instead of the employees. Why would we want that.
| kevmo314 wrote:
| This is an underrated reason why startups can be successful.
| Many large and even mid-sized companies' employees are
| encumbered in complexity indirectly because they need to
| engineer something to justify their jobs. I think a lot of
| devops is basically this sort of persona because if devops
| really did their jobs correctly, we shouldn't see so many
| devops jobs.
| bob1029 wrote:
| > While accidental complexity can arise innocently enough from
| well-intentioned engineers, the darker side is that it can
| manifest from ego and self-preservation.
|
| I am seeing a huge uptick in this style of "accidental"
| complexity.
|
| I recently had the pleasure of observing a _perfectly functional_
| T-SQL script be refactored to use entity framework, resulting in
| a ~50x decrease in throughput.
|
| Ignorance is something I am willing to entertain. Arrogance is
| way, way more difficult to deal with. One is an educational
| opportunity. The other is game of thrones.
| mrkeen wrote:
| With 0 examples, this isn't even a thinkpiece, it's a feelpiece.
|
| Let's pat ourselves on the back. _Their_ code is exciting and
| ego-driven. _Our_ code is boring and adds value. _They_ think
| they are facebook; we do not. _Their_ complexity is accidental.
| _Our_ complexity is essential. _Their_ engineers should stop
| adding features until their codebase is like _ours_.
| mrbungie wrote:
| It is a feelpiece, but I don't think that's necessarily a bad
| thing, at least it invites discussion.
|
| Also, framing it as "us vs them" misses the point. For
| instance, in my world (Data & Analytics), there's no universe
| where Spark makes sense for <1TB data or using Kafka for what
| could be solved using with more simple and predictable batch
| processing, yet we still see them used in wild implementations
| that clearly don't need that scale. Those implementations can
| end up needing a lot of headcount and budget for support
| without adding any value whatsoever and sometimes even ending
| up in a more brittle platform. Complexity often comes from
| misguided choices, not just ego.
|
| I've seen enormous data teams at startups, by that I mean
| bigger than WhatsApp engineering team in its prime pre-Meta
| (~30 people). That's a red flag, especially when they're
| processing far less data.
| moritzwarhier wrote:
| Inviting discussion through underspecified warnings or appeal
| to feelings of superiority, safety/caution or "best
| practices" is a very pervasive issue in software.
|
| I admit I did not read the article. But I have done so before
| I guess, I remember the headline.
|
| The headline is enough to provoke thought. See
|
| https://world.hey.com/dhh/merchants-of-complexity-4851301b
|
| And after clicking, I see, this article is very recent.
| Strange...
| mrbungie wrote:
| I'm not sure what to tell you, dismissing the article as
| posturing or superiority, without reading it, is at the
| very least ironic.
|
| That being said, I'd just add (and perhaps the article
| fails to acknowledge this, implying the author sees
| themselves as immune) that no one is completely safe from
| falling into these traps. We're more human than engineer,
| after all. It's easy to slip into complexity, for all sorts
| of reasons: ego, incentives, time pressure, misguided
| intellectual curiosity, or simply chasing what's familiar,
| even when familiar isn't the right fit for the context.
| Michelangelo11 wrote:
| https://grugbrain.dev/
| wcfrobert wrote:
| Past a certain scale, complexity is mostly unavoidable.
|
| Accidental complexity is compressable, but essential complexity
| is not. At some point, you cannot compress further without losing
| nuance.
|
| In compiler design, there's a concept called the waterbed theory
| of complexity which states that you can try to abstract
| complexity away, but it'll just show up elsewhere.
| tikhonj wrote:
| I don't like talking about "complexity" any more because while
| almost everyone agrees it is "bad", people have radically
| different ideas of what it _means_. "Complexity" in software
| conflates several distinct concepts:
|
| * plain poor design
|
| * complexity in operation rather than design (or technology)
|
| * inescapable real-world complexity
|
| * lots of moving pieces and details, straining working memory
|
| * abstract or novel concepts that are hard to _learn_ up-front,
| but easy longer-term
|
| Some of these are practically opposites! At the pareto frontier
| of good design, there is a pretty fundamental trade-off between
| having more abstract concepts that are harder to learn up-front,
| and exposing more details that make systems hard to work with on
| an ongoing basis. People just call both of these "complexity"!
| These are two concepts that absolutely should not be conflated.
|
| I've seen lots of other patterns that are misleadingly described
| as "complex". For example, some of the most effective software
| I've seen has been _situated_ software[1]; that is, software
| built _for_ , and largely _in_ a specific social context. Think
| seemingly messy code that is incestuously coupled to a single
| person 's or team's workflow. This software might actually be
| perfectly simple _in context_ , but it's going to seem painfully
| baroque to anybody _outside_ that context.
|
| [1]: https://gwern.net/doc/technology/2004-03-30-shirky-
| situateds...
|
| Given all I've seen, I've come to the conclusion that generic
| exhortations about "complexity" are actively harmful. If you're
| going to write a universally applicable rant, just write about
| how bad design is bad and good design is good! At least that's
| something that people will disagree with--I've met far more
| people who insist there is no such thing as "good" or "bad"
| design than people who insist that complexity is actually better
| than simplicity.
| moritzwarhier wrote:
| > Because that's the other side of this. There are rarely high
| margins in actually selling someone something that they then own.
| Much better to rent it to them. They'll own nothing and you'll
| convince them they should be happy.
|
| > By what sorcery? Fear, mostly. Vanity, sometimes. Sloth,
| occasionally. Pride, definitely. The more insecurities the
| merchants of complexity can trigger, the easier the sell.
|
| https://world.hey.com/dhh/merchants-of-complexity-4851301b
|
| You can also find blogs and podcasts about this subject, when DHH
| coined the phrase.
|
| Think about the topic what you will, but the submission looks
| like a regurgitation to me.
| readthenotes1 wrote:
| Those sorceries--
|
| https://en.m.wikipedia.org/wiki/Seven_deadly_sins
| moritzwarhier wrote:
| All in service of greed. Another one.
|
| Thinking about it: it's interesting bridge to utilitarianism
| (the other deadly sins enable the greed of the merchant).
|
| And also, the title ironically is itself an
| overgeneralization and appeal to fear/scrunity (though
| certainly not generally unjustified)
___________________________________________________________________
(page generated 2025-05-25 23:02 UTC)