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.

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.

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.

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.

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.

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

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.

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.

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.