by 7d7n on 5/5/24, 5:17 PM with 256 comments
by Ozzie_osman on 5/5/24, 5:59 PM
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.
by rsync on 5/5/24, 6:30 PM
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 ...
by AJRF on 5/5/24, 6:17 PM
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.
by hooby on 5/6/24, 5:40 AM
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.
by 2four2 on 5/5/24, 5:52 PM
by pornel on 5/6/24, 12:02 AM
"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.
by tolmasky on 5/5/24, 5:49 PM
by bbminner on 5/5/24, 6:49 PM
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.
by Puts on 5/6/24, 12:00 PM
by nickpeterson on 5/5/24, 6:05 PM
by Nevermark on 5/5/24, 7:16 PM
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.
by 3pm on 5/5/24, 6:01 PM
The COST of a given platform for a given problem is the hardware configuration required before the platform outperforms a competent single-threaded implementation.
“You can have a second computer once you’ve shown you know how to use the first one.” –Paul Barham
by Ozzie_osman on 5/5/24, 5:52 PM
"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.
by nelsondev on 5/5/24, 5:37 PM
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”
by BLKNSLVR on 5/6/24, 1:58 PM
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.
by dang on 5/6/24, 1:21 AM
Simplicity Is an Advantage but Sadly Complexity Sells Better - https://news.ycombinator.com/item?id=32491079 - Aug 2022 (6 comments)
by zeroCalories on 5/5/24, 6:07 PM
by boxed on 5/6/24, 11:37 AM
by cs702 on 5/5/24, 8:21 PM
> 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]
---
by rglover on 5/5/24, 9:10 PM
by austin-cheney on 5/5/24, 5:32 PM
by atomicbeanie on 5/6/24, 2:37 PM
by sesm on 5/6/24, 3:55 PM
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.
by sebastianconcpt on 5/6/24, 4:24 PM
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.
by scrlk on 5/5/24, 6:08 PM
by marcus_holmes on 5/6/24, 3:46 AM
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.
by IshKebab on 5/5/24, 7:12 PM
by hyperthesis on 5/6/24, 2:19 AM
by kouru225 on 5/5/24, 9:45 PM
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.
by quantum_state on 5/5/24, 5:58 PM
by hyperthesis on 5/6/24, 2:21 AM
Too easy -> easily copied -> and no long-term competitive advantgage. Complexity signals hard.
by kroolik on 5/6/24, 2:11 PM
As engineers, we are often tempted to challenge ourselves, straying away from the latter. There is less perceived pride from following simple solutions.
by renonce on 5/6/24, 4:50 PM
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.
by hyperthesis on 5/6/24, 2:06 AM
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.
by briantakita on 5/6/24, 4:17 PM
by daitangio on 5/7/24, 6:25 AM
For instance the ‘do not me think’ GUIs are more complex to design than a CRUD GUI pushing all form fields in a form.
by wccrawford on 5/6/24, 4:22 PM
by imtringued on 5/7/24, 6:23 AM
by mro_name on 5/5/24, 6:08 PM
But they go on nevertheless, stubborn as they are.
Edit: Oh, and the razor Occam was a franciscan, too.
by tipiirai on 5/6/24, 7:35 AM
Exactly my feeling with TypeScript
by galdor on 5/5/24, 5:47 PM
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.
by sebastianconcpt on 5/6/24, 4:25 PM
by 1vuio0pswjnm7 on 5/5/24, 11:08 PM
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.