Simplicity is an advantage but sadly complexity sells better (2022)

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.

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.

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

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.

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.

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 ...

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”

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.

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?

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.

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.

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.

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.

Simplicity is an advantage but complexity sells better

Exactly my feeling with TypeScript

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.

This is one of the reasons that IT is in a state of ruin …

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

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.

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.

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.

The simple solution is superior if it does everything you need. If it doesn't, the complex solution suddenly becomes a lot more desirable.

Which techniques have you developed to deal with this problem?

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.

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.

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.

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.

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.

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.

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.

"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.

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)

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

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.

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.

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.

Incompetence also qualifies billing a client substantially more time for a given work effort completely without fraud.

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.

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.

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.

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.

  “You can have a second computer once you’ve shown you know how to use the first one.” –Paul Barham

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.