Things have gotten more complex lately — I’m sure you’ve noticed.
Perhaps you’ve shrugged it off as an inevitable side-effect of progress.
Is it, though?
Increasing the number of components makes a system more complicated.
But entangling the individual components makes it complex.
A Swiss watch with its many gears is complicated. But there’s a manual. A watchmaker can repair it reliably.
The unpredictable behavior between components is what makes a system complex. Weather is complex. Cities are complex.
The problem isn’t the number of parts; it’s that the parts can’t be understood in isolation; you can’t pull one out without disturbing the others.
More components, more complicated.
More relationships between components, more complex.
Complication is an inevitable side-effect of solving harder problems.
On the other hand, complexity is a choice — one that is often made unconsciously while solving a problem. The irony is that by intertwining in the pursuit of an immediate solution, we shorten the solution’s lifespan.
We only need to peek at a few open-source projects to see this reality at work.
Dependencies reveal complexity
Naming is hard, but we got it right by calling packages “dependencies.” The more dependencies a project has, the more relationships, the more complexity.
If it’s true that complexity kills, then we should expect that the projects that survive have fewer dependencies.
I sampled 19 popular open-source web libraries and apps and found just that.
For scale, the average project in this list is 6.5 years old and has anywhere from
72k to 3M lines of code
11 to 340 dependencies
Lines of Code per Dependency
VSCode: 23,579
SuperProductivity: 21,173
Ionic Framework: 11,518
OpenClaw: 10,632
Posthog: 8,970
Playwright: 8,562
react-hook-form: 6,562
webpack: 6,050
social-analyzer: 6,022
excalidraw: 5,579
Cal.com: 4,039
Ionic Capacitor: 2,637
Remix: 1,795
Logseq: 1,772
drawdb: 1,495
Compass Calendar: 1,383
Vitest: 602
Formik: 566
The official winner is VSCode, with over 23,000 lines of code for each of its dependencies. As a low-level tool backed by Microsoft and the default app for every web dev for the past decade, this makes sense. There’s a lot of money and engineering time spent on keeping it lean-ish. But close behind is a productivity app with 614k lines of code and 29 dependencies backed by … one guy in Germany whose been working on it part-time for the last nine years!
SuperProductivity has endured because it has resisted complexity.
Compass is similar to SuperProductivity in spirit. Yet it’s at the bottom of the list because its developer has eaten from the forbidden fruit of the npm tree (and suffered greatly as a result).
The OGs at Remix are wiser; they’ve made the avoidance of dependencies a core principle:
Avoid Dependencies. Dependencies lock you into somebody else’s roadmap. Choose them wisely, wrap them completely, and expect to replace most of them with our own package eventually. The goal is zero.
— Remix’s README
This relationship between complexity and longevity is not unique to the open-source projects I cherry-picked. Just look at your own team’s graveyard of archived repos. I’ll bet the ones that didn’t make it have a lot of complex relationships.
Simplicity is prerequisite for reliability.
— Edsger W Dijkstra
We can choose differently now
Now that software is cheap, we’re forced to confront the question, “Do things still need to be this complex?” A triple-decker of abstractions might’ve been justifiable in a big codebase maintained by 500 engineers, each of whom can only keep 5% of the system in their head. But if that same team “reorgs” to 100 engineers and 400 coding agents, each of which can hold 100% of the system in context, could we travel more lightly?
Yes, and it’s already happening. Cloudflare rebuilt Next.js sans opinionated build system with one engineer in one week (cloudflare.com). Anthropic built a C compiler from scratch with 16 agents and $20k (anthropic.com).
The abundance of subsidized tokens encourages the creation of unadulterated projects like these headline-grabbers. But it also offers a unique opportunity to right our wrongs, to absolve the complexity we’ve accrued during times of weakness.
These days, I wake up with foaming bloodlust towards my package.json, for I know that the more complexity I expunge, the longer the software can survive.
There’s an irony here, one that mirrors the opportunity presented by social media.
As we’re bombarded with cheap dopamine, it’s never been easier to settle into chronic distraction. It’s also never been easier to compete: just read a book for five minutes to become a top 84% reader in the US (bls.gov).
We’re always one prompt away from a PR that introduces more complexity. But we’re also always one prompt away from a PR that cleans up the old.
Reply to LMK if you’re a fellow soul who gets more excited about removing the old than adding the new.