Carmack on Quake-era id: too many novel systems, one bus factor

What happened

John Carmack — co-founder of id Software, the engineer behind Doom, Quake, and basically every 3D rendering technique a generation of game devs learned — posted a retrospective thread on the mistakes around Quake that, in his telling, ended id's run as the most dangerous shop in the industry. It's the latest in a series of unusually candid post-mortems Carmack has published since leaving Meta, and it lands in front of an audience that has spent thirty years treating him as the platonic ideal of the principal engineer.

The headline finding isn't that Romero left, or that the team fractured, or that Daikatana happened to somebody else — it's that id tried to ship a brand-new 3D renderer, a client-server netcode rewrite, an embedded scripting language (QuakeC), and a new level editor with roughly the same headcount that had shipped Doom. Each of those was a research project. Stacked, they were a 14-person studio attempting the work of four. The Quake that eventually shipped in June 1996 was a brilliant piece of software and a visibly compromised game — late, scoped down from its original RPG-adjacent design, and shipped by a team that did not survive contact with itself. Romero was out within months. American McGee, Sandy Petersen, Mike Abrash, and most of the original creative spine followed across the next two years.

Carmack's framing now is engineering management, not nostalgia. The technical wins (BSP rendering on consumer hardware, a real internet-playable shooter, a moddable scripting layer that arguably invented the modern Source/Unreal mod ecosystem) are not in dispute. The complaint is that doing all of them in one release cycle, with one chief engineer, with no tools team and no infrastructure investment, was the move that turned a generational lead into a fifteen-year cleanup project that culminated in Doom 3 shipping in 2004.

Why it matters

The reason this lands in 2026 — and the reason it's a top-of-HN thread instead of a footnote in a games-history book — is that the failure mode Carmack is describing is the exact failure mode of roughly half the AI-infrastructure startups currently raising Series B. Building a novel runtime, a novel storage layer, a novel orchestration substrate, and a novel UX all in the same release cycle, with the same fifteen engineers, is the Quake mistake in a different language. The shape of the org chart is the shape of the bug.

Carmack is also implicitly retracting the romantic version of the id story — the one where the company's collapse is a designer-vs-engineer morality play. The Romero schism is the part everyone remembers because the personalities were vivid, but it was downstream of a deeper structural problem: id had no second-string engineer who could own any of the four novel subsystems Carmack was holding in his head. When Mike Abrash left for Microsoft (RealAudio, then graphics), there was no bench. The bus factor on Quake's rendering pipeline was, generously, 1.5. Carmack's own retrospective on QuakeC has historically been that it was over-engineered for what mods actually wanted, and that a simpler data-driven trigger system would have done 90% of the job with 10% of the maintenance cost — but the team didn't have the bandwidth to figure that out in the moment because the same engineer was also debugging the netcode.

The community reaction on Hacker News is split along predictable lines. Senior engineers who lived through 90s shareware are reading it as vindication of "boring tech, novel game." Younger commenters are pointing out, fairly, that id's competitive position was so dominant that even a botched Quake era left them with the IP, the engine licensing revenue, and the open-source legacy that still seeds Half-Life, Counter-Strike, and the entire Source lineage. Both are right. The Quake era was simultaneously a commercial success, a technical landmark, and an organizational failure — and Carmack is the rare principal who is willing to grade his own work on all three axes at once.

There's also a quieter point in the thread that's worth pulling out: id under-invested in tools and content pipelines. The level editor was an afterthought. Artists wrote shell scripts to convert assets. The build process was tribal knowledge. Every studio that out-shipped id in the late 90s — Valve, Epic, Blizzard — did so on the strength of tooling and content-production infrastructure that id never built, because the chief engineer was busy on the renderer. This is the part that maps most cleanly onto modern infra startups: the team that wins is rarely the team with the best core runtime, it's the team whose internal developer experience lets the next ten hires be productive in a week instead of a quarter.

What this means for your stack

Three concrete takeaways for anyone running an engineering team in 2026, all of them annoyingly obvious in retrospect and routinely ignored in practice.

First: pick one novel system per release. Everything else is boring tech, off-the-shelf, or skipped. If your roadmap has a new storage engine, a new query planner, a new auth model, and a new UI framework, you are not shipping any of them. You are shipping a debugging marathon with a launch date attached. Carmack could get away with two novel systems per Doom/Wolfenstein cycle because the rest of the stack was a 320x200 framebuffer and a parallel-port joystick. Quake had no such ballast.

Second: bus factor is a hiring problem, not a documentation problem. id didn't fail because Carmack didn't write enough comments. It failed because there was no second engineer who could have owned the netcode if Carmack had been hit by the proverbial bus, or — more realistically — pulled into a six-month rendering rabbit hole. If your most senior engineer is the only person who understands your hot path, you are running id circa 1995, and you should be hiring a peer rather than another junior.

Third: tools are the product. The studios that ate id's lunch shipped worse renderers and better editors. Hammer (Valve) and UnrealEd (Epic) were not technically superior to QuakeEd — they were just usable by humans who were not John Carmack. In a modern context: your internal CLI, your migration tooling, your local dev loop, and your error-message quality are not overhead. They are the substrate that determines whether your next ten engineers ship anything at all.

Looking ahead

The interesting thing about Carmack publishing this in 2026 is the audience he's writing for. id's open-sourcing of every engine through Doom 3 means an entire generation of engineers learned C from the Quake source tree. That same generation is now running infrastructure teams, founding AI companies, and making the exact scope mistakes Carmack just described — except now the novel-systems-per-release count is closer to six, and the chief engineer is a foundation model that hallucinates. The Quake post-mortem is thirty years late and exactly on time. Read it as an engineer, not as a fan.