Preventing the Collapse of Civilization

Jonathan Blow gave this hour-long talk at DevGAMM in 2019, and in the seven years since it has quietly become one of the most-cited critiques of modern software engineering. Blow — the game designer behind Braid and The Witness, and the creator of the Jai programming language — makes a claim most programmers instinctively resist: technological knowledge is not on a monotonic climb. Civilizations lose capabilities all the time. Ours is probably losing them right now, and software is one of the leading indicators.

This is our Classic of the Week — a foundational cultural artifact of the software profession, still ringing true, and arguably more relevant in an era where AI-generated code is layered on top of AI-assisted frameworks on top of container runtimes on top of virtualized OSes.

The Apollo argument: we’ve done this before, in reverse

Blow opens with the Apollo program. In 1961, Kennedy committed the US to landing on the moon within the decade — a target that, by any technical yardstick of the time, was insane. They did it. By 1969, humans walked on the moon; by 1972, they were driving on it.

Then look at the trajectory since:

• Apollo (1969–1972): moon landings, Saturn V, lunar rovers.
• Space Shuttle (1981–2011): low‑Earth orbit only.
• 2011–2020: the US could not fly humans to space at all — Americans rode Russian Soyuz capsules.
• 2020s: SpaceX brings capability back through private investment and deliberate effort.

The lesson isn’t “space is hard.” It’s that capability decayed between 1969 and 2011. The decay was not inevitable. It happened because the industrial base, the tacit knowledge, and the political will that produced Saturn V were allowed to disperse. Bringing capability back required intentional, expensive re-work by someone (Elon Musk, in this case) who explicitly refused to accept the decline.

This is not a mistake — this idea that technology just automatically improves. Great civilizations like ancient Egypt were able to make the pyramids, and then that knowledge was lost.

Lost technologies: Lycurgus and Antikythera

Blow presents two exhibits from further back:

The Lycurgus Cup (4th century Roman): a chalice that appears green in reflected light and red in transmitted light. The effect is produced by 50–70 nanometer particles of silver and gold dispersed in the glass. This is nanotechnology, in 300 AD. When the Roman Empire fell, so did the knowledge to produce it. We only relearned how in the modern era.

The Antikythera mechanism (c. 100 BC): a bronze mechanical calendar that computed lunar phases, planetary positions, and even predicted the timing of the ancient Olympic Games. Modern reconstructions show it contained dozens of intricately-cut gears working in concert. This level of geared computation was not seen again in Europe for over a thousand years.

The pattern Blow wants you to see: technologies get invented, refined over centuries, and then vanish when the civilization that maintained them collapses or reorganizes. It’s the default, not the exception.

The Bronze Age collapse — his central metaphor

Blow’s most sustained example is the Late Bronze Age Collapse of ~1177 BC. Around the Mediterranean, a network of civilizations — Egypt, Mycenae, Hittites, Ugarit, Cyprus, Babylon — had developed a fragile, high-value system:

• Bronze required both copper and tin. Copper came from Cyprus. Tin came from Afghanistan, thousands of miles away.
• Trade networks kept the whole thing running.
• When the networks broke (theories vary: climate, migrations, warfare), the entire connected system collapsed within a generation.
• Cities burned. Languages were lost — some Bronze Age scripts still haven’t been deciphered.
• The Mediterranean spent centuries in a “dark age” of vastly reduced capability.

The analogy Blow draws to software is explicit: modern software is a similarly networked, similarly fragile, similarly-dependent-on-a-supply-chain system. And, more provocatively, it is degrading right now in ways we’ve collectively normalized.

The Photoshop bug (and the software rot demo)

The middle third of the talk is a demo. Blow walks through his actual workday and shows the audience how many software bugs he hits per hour just doing normal work: Adobe Photoshop launching a broken New Document dialog; Emacs failing to reload modified files; a Steam game requiring a client restart to install; Visual Studio raising cryptic dialog boxes; websites rejecting valid phone numbers.

The point isn’t to shame these vendors. It’s the standard of quality has silently collapsed:

Computers always had a reputation for being a little bit funny. But you didn’t used to be like “yeah it’s software, restart it, whatever.” And that didn’t used to be. If our standards are shrinking over time, how low can they shrink before it becomes unsustainable?

The rhetorical move: he isn’t claiming things used to be perfect. He’s claiming that thirty years ago, hitting three UI bugs in one hour would have been an outrage. Today it’s Tuesday. That shift in tolerance is the decay.

Complexity vs. carrying capacity

The theoretical spine of the talk: every civilization has a maximum complexity it can carry, determined by the number of people, their training, and how well they transmit knowledge. Push complexity above the carrying capacity and:

• Fewer and fewer people fully understand any given system.
• Knowledge transmission fails — when the graybeards retire, their tacit expertise doesn’t survive them.
• The system becomes brittle: it can still run, but it can’t be repaired, extended, or reproduced from scratch.

Blow’s example: transistor logic. The first generation was designed by engineers who deeply understood inductive spikes and cross-chip interference. Later generations of chip designers, working at higher levels of abstraction, didn’t know to design against those effects. Bugs proliferated. The knowledge existed, but it wasn’t being transmitted.

Applied to software, his examples pile up:

• You can no longer just copy a program from one machine to another. You need installers, containers, package managers, CI, dependency resolvers.
• Microsoft’s “find my libraries” utility is 7,000 lines of code to answer what should be a two-line question.
• Language Server Protocol turns “look up this identifier” — a task solved cleanly by editors in the 1980s — into a distributed system running a background server per language.
• Game engines like Unity and Unreal were built by engineers who came up making engines. Nobody makes engines any more — so nobody has the training to build the next generation, and the current ones just decay.

The abstraction problem

The most quotable segment. Every level of abstraction we climb is supposed to be a productivity win. Blow’s counter‑claim: the productivity gains at higher abstraction levels are smaller than we think, and the losses in capability are larger than we admit.

He references Ken Thompson writing Unix — kernel, assembler, editor, shell — largely alone during the three weeks his wife was on vacation. Compare to modern development, with thousands of engineers, and ask: are we thousands of times more productive? Blow argues no, we’ve just accepted that the layers below us are somebody else’s problem, and when they break we can’t fix them.

The AI-era coda he doesn’t quite name (but which the audience felt in 2019 and feels more sharply now): letting AI navigate the complexity for us is not the same as understanding it. If nobody can build a compiler, and only the AI can maintain the AI-generated code, we have not solved the complexity problem — we have hidden it behind an oracle that we ourselves can no longer inspect.

Why programmers, specifically, should care

Blow ends with a personal pitch: even if you don’t buy the civilizational-collapse framing, you should care about this because it’s your job. Software’s declining robustness and declining developer productivity are already showing up in your day. If nobody works on knowledge about how to simplify — which sounds basic but Blow argues we barely have anymore — then the future of the profession is deeply mediocre in the way that America’s space program was deeply mediocre from 1980 to 2010.

Simplification is a form of engineering that we’ve lost.

Key takeaways

1. Technology does not automatically improve. Capabilities are lost all the time — Apollo, Antikythera, Lycurgus glass. Assuming perpetual progress is historically illiterate.
2. The Bronze Age Collapse is a better mental model for software than Moore’s Law. Networked, specialized, brittle systems collapse together when a link breaks.
3. Standards of software quality have silently degraded. The bugs Blow demos are normal. Fifty years ago they’d have been outrageous.
4. Every civilization has a maximum complexity it can carry — bounded by population, training, and how well knowledge transmits generationally.
5. Abstraction is not free. Climbing the ladder trades understanding of the ground below for productivity gains that turn out to be smaller than advertised.
6. Knowledge transmission is the real bottleneck. When the engineers who built the current systems retire without teaching successors, capability decays even if the systems keep running.
7. Simplification is an engineering discipline. We used to have it (Unix, C, early graphics APIs). We mostly don’t now. Recovering it is not glamorous but is where the biggest wins live.
8. You, personally, are affected. Even absent civilizational collapse, the trajectory of software quality bends against you as a working programmer. Simplifying your corner of the stack is legitimate high-leverage work.

Source

• Title: Preventing the Collapse of Civilization
• Speaker: Jonathan Blow (Thekla, Inc.; creator of Braid, The Witness, and the Jai language)
• Venue: DevGAMM Talks (Moscow, 2019)
• Duration: 62 min (plus Q&A)
• URL: https://www.youtube.com/watch?v=ZSRHeXYDLko