Skip to content
Published on

Technical Overreach and Scope — Lessons from Carmacks Retrospective

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Introduction — Why Carmacks Retrospective Is Trending Now

In 2026, Hacker News and GeekNews have a recurring pattern of old source code and development retrospectives surfacing anew. The more AI pours out code rapidly, the more, paradoxically, the fundamental question "what does it mean to build well" draws attention again. At the center of that, John Carmacks retrospectives circulate once more.

Carmack is the programmer who built Wolfenstein 3D, Doom, and Quake at id Software, one of the most notable figures in the history of game engines and graphics programming. He is also famous for sharing his development process relatively candidly. In particular, Quake development is something he has recalled in various interviews and public writings as "a period where ambition collided with reality."

This article is not a biography of Carmack the person. Using his publicly shared retrospective as a clue, it attempts to draw out universal lessons that every engineering team faces — technical overreach, scope management, choosing stable foundations, and small-team decision-making.

Why does such a retrospective draw renewed attention precisely in 2026? Now that AI coding agents have all but removed the bottleneck of code production, many teams are caught in the excitement of "we can now try more things, faster." Yet that very excitement is also a straight path to the trap Carmack warned about — trying too many things at once. The fact that you can produce code quickly does not mean you can carry many big risks simultaneously. If anything, the faster production gets, the more the restraint of deciding what not to try matters. This is exactly why a thirty-year-old retrospective reads as fresh today.

Important: This article is based on public reporting about Carmack and id Software, and on retrospectives he has shared directly. It invents no fictional dialogue put in anyone's mouth, and treats specific factual citations cautiously. The details of anecdotes may differ by source.

Factual Background — What Quake Development Left Behind

First, let us lay out the publicly known facts.

id Software built Quake after the success of Doom. Quake, released in 1996, is regarded as a game that combined truly real-time 3D polygon rendering with multiplayer networking. Technically, Quake pursued several very ambitious goals simultaneously for its time.

Widely known facts can be summarized as follows.

  • Quake aimed at a fully 3D world, going beyond Doom's 2.5D approach.
  • Carmack solved real-time 3D rendering performance problems with techniques like BSP trees, precomputed visibility (PVS), and lightmaps.
  • Quake pointed the direction of online gaming with internet multiplayer and a client-server model.
  • It introduced QuakeC, a scripting language for game logic, opening a modding ecosystem.

At the same time, Quake development is also recalled as a period that left great strain and conflict at id Software. That the game's design direction changed mid-development, and that there was a substantial gap between the early vision and the final product, is commonly mentioned across many sources. Through this period, some key personnel left the company.

Carmack himself later, in various interviews and writings, left retrospectives to the effect that the ambition at the time was too large and that too many new things were attempted at once. The lesson this article addresses is exactly this point: "the danger of attempting too many things at once."

One thing to make clear is that this article in no way means to portray Quake as a "failure." Quake was a great success both commercially and technically, and it laid the foundation for online multiplayer games and modding culture. What the retrospective focuses on is not whether the result succeeded but the cost of the process. Could the same success have been reached with less pain, and what amplified that pain — this is the focus of the lesson. Honestly looking back on the process of a successful project is itself the most valuable kind of retrospective.

Lesson 1 — Only One Big Risk at a Time

The Multiplication of Risk

Attempting something new in an engineering project carries risk. And when you attempt several new things simultaneously, risk does not add up — it multiplies.

  One big gamble at a time (recommended)
  +------------------+------------------+
  | proven base      | one new attempt  |
  | (stable)         | (risky)          |
  +------------------+------------------+
  risk = 1 (manageable)

  Many big gambles at once (risky)
  +----------+----------+----------+----------+
  | new      | new      | new      | new      |
  | rendering| network  | language | design   |
  | (risky)  | (risky)  | (risky)  | (risky)  |
  +----------+----------+----------+----------+
  risk = multiplied (hard even to tell where it broke)

Recall what Quake pursued simultaneously. Fully 3D rendering (new), internet multiplayer (new), a scripting language (new), and a shifting game design (uncertain). Each was a hard challenge in itself, and these proceeded at the same time.

When a problem arises in this situation, isolating the cause is very hard. When performance falls short, it is hard to tell whether it is the rendering, the network, the scripting, or the interaction of the three. When risk multiplies, so does debugging.

Universal Application

This lesson applies beyond games to all engineering.

  • Do not introduce a new programming language for the first time while simultaneously trying a new architecture and simultaneously moving to new infrastructure.
  • Do not put a new database, a new queue system, and a new deployment method all into one release.
  • If you stack several unproven technologies at once, isolating the cause when a problem occurs becomes impossible.

The first thing to break down when you violate this principle is your debugging ability. The diagram below shows why.

  When there is 1 new thing (isolatable)
    problem occurs -> 1 suspect -> fast diagnosis

  When there are 4 new things (not isolatable)
    problem occurs -> 4 suspects + 6 interaction pairs among them
                   -> 10 possibilities total -> diagnosis paralysis

When suspects increase, they do not simply add up; you must also suspect the interactions among them. Four new things create six interaction-pair suspects on top of the four standalone suspects. This is the concrete meaning of saying risk multiplies.

The principle is simple: "only one big gamble at a time." Fill the rest with proven, boring, stable choices. That way, even if the gamble fails, you can clearly identify and respond to that failure.

The Risk Budget Way of Thinking

A more practical way to handle this principle is to think in terms of a "risk budget." You assume there is a limit to the total amount of novelty a single project can bear, and you consciously allocate that budget.

  A project's risk budget (e.g., 100 points)

  +--------------------------------------+
  | 1 core differentiating gamble : 60   |  <- concentrate here
  | small novelty in support areas: 20   |
  | everything else proven        : 0    |
  | slack (unexpected risk)       : 20   |  <- always leave this
  +--------------------------------------+
  total 100 points (do not exceed)

There are two cores to this way of thinking. First, the recognition that the budget is finite. Every time you add one more new thing, you must subtract risk somewhere else. Second, leaving slack. If you spend the entire risk budget on planned gambles, you have no capacity to absorb unexpected risks (dependency problems, personnel departures, requirement changes) when they hit.

Viewed through this frame, Quake allocated its risk budget to several big gambles at once and had almost no slack. So when the additional risk of a design change struck, there was insufficient capacity to absorb it. This is not a reproach but a price commonly paid by projects pushing the boundaries of the industry.

Of course, the number "100-point risk budget" is only a metaphor; it does not mean risk can actually be quantified precisely. The value of this way of thinking lies not in exact calculation but in forcing you to consciously count "how many big gambles are we carrying at once right now." The reason many teams collapse is not that they miscalculated risk, but that they never even counted how many risks they had taken on.

Lesson 2 — The Value of Choosing Stable Foundations

The Virtue of Boring Technology

One consistent feature of Carmack's work is that he distinguished the flashy parts from the boring parts and built the boring parts solidly. He often stacked innovation atop proven algorithms and data structures. The BSP tree was not something he invented but something he took from existing computer graphics literature and applied to games.

A universal lesson emerges here. Innovation need not happen in every layer simultaneously. Rather, projects that work well fill most layers with boring, proven things and concentrate innovation in only the one or two layers that truly need differentiation.

  Layer              Strategy
  -----------        ---------------------------
  core differentiator innovation (worth the risk)
  support systems     proven patterns (boring is a virtue)
  infra/foundation    most stable choice (never gamble)

If the foundation wobbles, everything atop it wobbles. So the lower the layer, the more conservatively, the more proven a choice you must make. Save the gambles for the upper layers, the differentiation points where the user feels value.

A Modern Reading of "Boring Is a Virtue"

This principle holds in 2026 too. The reason the advice to "choose boring technology" circulates widely today is exactly this. New technology is alluring, but laying unproven new technology in the core foundation propagates that risk everywhere.

Especially in an era where AI generates code rapidly, this principle becomes more important. Being able to make code fast does not mean it is fine to stack several unproven technologies at once. The faster generation gets, the more decisive the judgment of what to fix as the stable foundation becomes.

Innovation Also Comes from Combination

Here we must address a common misunderstanding: "choose boring technology" does not mean "do not innovate." The fact that Carmack did not invent the BSP tree does not make his work less innovative. Rather, he created innovation by combining and applying existing, proven techniques in the new context of games.

  Two kinds of innovation

  Invention-type innovation    Combination-type innovation
  -------------------          -------------------------
  builds something wholly new  newly combines proven things
  risk is very high            risk is relatively low
  succeeds rarely              succeeds often
  e.g., inventing an algorithm e.g., clever use of existing ones

Most successful product innovation is not invention-type but combination-type. You use proven parts stably while creating differentiation in the way you combine them. This lets you innovate while conserving your risk budget. "Clever combination atop boring technology" is the very path that captures stability and innovation at once.

This perspective greatly eases the burden of tool selection. It frees you from the pressure of having to chase the newest technology in every layer and moves you to the more productive question of "where do we use proven things, and where do we combine cleverly." The team that wins is not the one that uses the most of the newest things, but the one that arranges the new and the proven most cleverly.

Lesson 3 — Scope Management and Technical Debt

The Danger of Shifting Scope

Another theme repeatedly mentioned in Quake development retrospectives is that the game design direction changed mid-development. The narrative that more ambitious RPG-like elements were envisioned early on but converged to the final form amid technical reality and schedule pressure appears commonly across many sources.

Scope wobbling mid-development is a classic trap of every project. A particularly dangerous combination is "ambitious scope + shifting scope + tight schedule." When these three overlap, the team burns out chasing an endlessly moving target.

  The triangle of scope risk

         ambitious scope
            /\
           /  \
          /    \
         /      \
  shifting ----- tight
   scope          schedule

  if all three sides are long -> burnout and quality collapse

Technical Debt Must Be a Conscious Decision

In ambitious projects, technical debt is inevitable. Between schedule and ambition, something gets deferred, stopgaps go in, and "fix it later" piles up. The problem is not the debt itself but the debt accumulating unconsciously.

The difference between healthy and unhealthy teams is not the presence of debt but its visibility.

  Bad technical debt          Healthy technical debt
  -------------------        -------------------------
  accumulates unconsciously   chosen consciously
  do not know where it is     tracked as a list
  no plan to repay            a repayment time is set
  compounds                   interest is managed

Generalizing the lesson of Carmack's retrospective: it is not to reduce ambition, but to be aware of, track, and control the debt that accompanies ambition. If you know where you cut corners, you can restore it later; if you cut corners unknowingly, that collapses the system one day.

Early Signals of Scope Creep

Scope wobbling dangerously usually sends signals long before the schedule explodes. Catching these signals early buys you time to respond.

  Early signal                    Meaning
  -------------------------       -------------------------
  "while we're at it" recurs      scope is creeping upward
  demos keep slipping             the critical path is uncertain
  "almost done" repeats           90% syndrome, last 10% won't finish
  estimates miss badly each time  the problem isn't understood enough
  key people normalize overtime   the human cost is already being billed

The most dangerous of these signals is the last. Because the mismatch between schedule and scope is ultimately absorbed by people's overtime and burnout, "the team looks exhausted" is often the most honest indicator of a scope problem. People's faces speak before the numbers on a dashboard do.

The response is simple but hard: reduce scope, extend the schedule, or lower ambition. None of the three is free, and refusing all three leaves only the path of grinding people down. A healthy team chooses one of the three early and consciously.

Lesson 4 — Small-Team Decision-Making and Human Cost

The Double Edge of Small Teams

id Software was a small team. Small teams have the strengths of fast decisions, high cohesion, and low communication overhead. That one or two key people like Carmack could strongly drive the technical direction was possible precisely because the team was small.

But small teams have shadows too. Dependence on key personnel is high, conflict among a few shakes the whole team, and one person's burnout threatens the project. That some key personnel left the company during Quake development shows that technical ambition and human cost are not separable.

  Small-team strength         Small-team risk
  -------------------        -------------------------
  fast decisions              dependence on key people
  high cohesion               conflict among a few is fatal
  low overhead                vulnerable to burnout
  strong direction            low bus factor

Technical Decisions Are People Decisions

Here emerges the most important general lesson. Technical overreach does not end as a purely technical problem. It is passed to people as schedule pressure, overtime, frustration, and conflict. Too-ambitious scope is ultimately filled by grinding people down, and that cost is billed as the departure of key personnel.

So balancing ambition and reality is not merely schedule management but people management. When deciding which technologies to attempt, if you do not also ask "what human cost does this demand of the team," you can succeed technically yet lose the team.

Managing Strong Opinions and Conflict

Another feature of small teams is that when a few people with strong opinions clash, that friction immediately becomes the whole team's problem. In a large organization, disagreements are spread and buffered across many layers, but in a team that runs on three or four key people, a feud between two is itself a company crisis.

The more technically ambitious a team, the more it gathers people with strong opinions. This is both an advantage and a risk. Strong opinions produce good decisions, but when those opinions collide and there is no mechanism to reconcile them, the team splits. So the smaller the team, the more important an explicit agreement on "how do we handle disagreement" becomes — who holds final decision authority over which area, and how to proceed when consensus fails. The way conflict is resolved is as much an object of design as the technical direction.

Interestingly, the most common antidote to this problem is not some grand process but record-keeping. Leaving even a brief note of "why we made this decision" prevents the same argument from recurring later, and helps even those who disagreed with the decision understand its context. Small teams want to skip records for speed, but a record of key decisions is in fact an investment that reduces conflict and increases speed.

Lesson 5 — The Discipline of Finishing and Shipping

Shipping Is the Proving Ground of Ambition

Another reason id Software is talked about is that they were ambitious and actually shipped. Doom and Quake did not end as concepts; they came out into the world. The difference between a project that endlessly inflates its ambition and never ships, and one that halts its ambition in reality and ships, is decisive.

  Ambition that does not ship      Ambition that ships
  -------------------              -------------------------
  "just a little more perfect"     "good enough to ship, rest next time"
  scope expands infinitely         scope is consciously frozen
  eternal 90%                      a clear shipping bar
  no feedback from the world       the world verifies it

Shipping requires the discipline to halt ambition — the decision to draw the line between what belongs to this version and what belongs to the next. If you cannot draw this line, scope expands infinitely and the product never ships. Paradoxically, the surest way to realize ambition is the restraint of deferring part of that ambition to next time.

Iteration Beats One-Time Perfection

Here emerges another lesson. The ambition to ship quickly and iterate is usually stronger than the ambition to build something perfect in one shot. The progression from Doom to Quake and from Quake to the next generation came not from one-time perfection but from the repetition of shipping and learning.

This connects to the risk budget too. Cramming all ambition into one version multiplies risk, but dividing ambition across several versions makes each version's risk manageable and lets the world's feedback correct the next ambition with every release. Several solid steps go farther than one big leap.

Translating to a Modern Case — A Startup Re-enactment

To show that these lessons are not just a story about a game company thirty years ago, let me illustrate with a common modern startup scenario. This is a hypothetical case.

A Series A startup decides on an ambitious v2 rewrite. They decide to change all of the following at once.

  Novelties attempted at once in v2 (risk multiplication)
  +----------------------------------------------+
  | 1. monolith -> microservices (new arch)      |
  | 2. REST -> GraphQL (new API paradigm)        |
  | 3. a new language used for the first time    |
  | 4. migration to a new cloud (new infra)      |
  | 5. a new design system (shifting scope)      |
  +----------------------------------------------+

The result structurally resembles Carmack's retrospective. The schedule keeps slipping, it is hard to isolate where problems break out (the interaction of five novelties), overtime piles up, and two key engineers leave to burnout. It is the same pattern of technical ambition being billed as human cost.

What if they had applied the risk-budget way of thinking? They would have asked first, "what is the core differentiator of this v2," and assigned the big gamble only there. For instance, if the move to microservices is truly the core, they would do that one thing and keep proven existing choices for the rest (language, API, infra, design). Then even if problems break out, they can isolate them as "the microservices' fault," and absorb unexpected risk with the slack budget.

The lesson of this case is clear. The temptation of a rewrite incites the greed of "while we're rebuilding anyway, let's make everything modern," but that very greed is the most common path to multiplying risk.

Successful rewrites usually proceed one thing at a time, incrementally, verifying at each step. This is exactly the statistical reason big-bang rewrites that change everything at once fail. Instead of shouldering all the risk at once, the team that replaces one piece at a time and confirms stability at each step ends up reaching the destination faster and more safely.

Practical Application — A Checklist for Handling Ambition

Here are the lessons drawn from Carmack's retrospective as a practical checklist.

[ Risk isolation ]
[ ] Do you keep the "one big gamble at a time" principle in this project?
[ ] How many unproven technologies are you stacking at once?
[ ] Did you separate the new so you can isolate the cause when problems arise?

[ Foundation choice ]
[ ] Did you choose the most proven thing for the lowest layer (infra/foundation)?
[ ] Did you concentrate innovation only on the core differentiation point?
[ ] Did you choose "boring technology" where you could?

[ Scope and debt ]
[ ] Is scope clearly defined and are changes controlled?
[ ] Do you track consciously-taken technical debt as a list?
[ ] Is it debt with a repayment time and an owner set?

[ People ]
[ ] Did you assess the human cost this ambition demands of the team?
[ ] Is there a way to reduce key-person dependence (bus factor)?
[ ] Do you have a system to monitor burnout signals?

[ Ship discipline ]
[ ] Is this version's scope boundary (what gets deferred to next) clear?
[ ] Is a clear shipping bar defined? (prevents 90% syndrome)
[ ] Did you divide ambition across several iterations (versions)?

The core of this checklist is not to give up ambition. It is to pursue ambition consciously, separated, and with people in mind.

Frequently Asked Questions

Q1. So are you saying not to do ambitious projects?

The exact opposite. Had id Software not been ambitious, there would be no Doom and no Quake. The lesson is not "abandon ambition" but "concentrate ambition in one place and stabilize the rest." If you pour your risk budget into a single big gamble, that gamble is actually more likely to succeed. It is ambition scattered in all directions that is dangerous.

Q2. How do you decide what the "core differentiator" is?

Ask, "without this, is there any reason for our product to exist?" For Quake, that was real-time 3D. Assign the big gamble only to areas where the answer is "yes," and make the most boring, proven choices for areas where the answer is "no" (build tools, deployment method, auxiliary libraries).

Q3. Isn't technical debt always bad?

No. Debt taken on intentionally can be a reasonable strategy. The problem is unconscious debt, and debt with no plan to repay. If, to meet an ambitious schedule, you explicitly decide and record "this is a stopgap for now, to be refactored within two weeks of shipping," that is healthy debt. The crux is not the debt itself but its visibility and repayment plan.

Q4. How do you reduce a small team's bus-factor problem?

The basics are to intentionally have two or more people touch core areas (pairing, rotation) and to leave a written record of "why we built it this way." The smaller the team, the greater the temptation to concentrate on one person for speed, but the cost at the moment that person leaves is far greater than the everyday cost of distribution.

Q5. Does this lesson still hold now that AI writes code fast?

It holds even more. AI raises the speed of code production, but the problem that "it is hard to isolate the cause when you try several new things at once" has nothing to do with code-production speed. Being able to make a lot quickly does not mean you can carry many big gambles at once. The multiplication of risk remains the same in the AI era. Moreover, the easier AI makes it to build code, the greater the temptation of "while we're at it, let's redo everything." So the need for restraint does not shrink — it grows.

Q6. If you had to compress these lessons into one sentence?

"Concentrate ambition in one place, keep the rest boring, make debt visible, care for people, and stop to ship." This one sentence is the compression of the five lessons.

Pitfalls and a Critical View

Here are the cautions when drawing lessons from Carmack's retrospective.

  1. The risk of hindsight rationalization: a retrospective is narration after knowing the result. The judgment "we were too ambitious then" may have come because it turned out hard; had it succeeded, the same choice might have been praised as "bold vision." When drawing lessons from retrospectives, beware survivorship bias and hindsight bias.
  2. The risk of devaluing ambition: applying "only one at a time" excessively slides into conservatism. It is also a fact that id Software took risks, which is why Doom and Quake changed the industry. Reduce all gambles and only mediocrity remains. The lesson is not "do not gamble" but "manage the gamble."
  3. Differences in context: 1990s game development and today's software development differ in tools, team size, and market. It is hard to transplant the lessons of an era when one genius programmer wrote an engine directly onto modern teams. One must separate the universal parts (risk isolation, scope management) from the era-specific parts.
  4. The trap of hero narrative: a narrative centered on a figure like Carmack easily reinforces the hero myth of "one genius." The actual product is the collective effort of designers, artists, and other programmers, and reconstructing the whole from one person's viewpoint in a retrospective creates distortion.
  5. The limits of sources: even the same event is remembered and interpreted differently by each participant. Even the "commonly mentioned" facts this article cites may not be a complete consensus. A stance of not accepting a single retrospective as absolute truth is needed.
  6. Success does not justify the choices: the fact that Quake ultimately succeeded is not evidence that the choices in its process were right. Beware the "success-halo effect" that retroactively justifies every decision of a successful project. Perhaps the same success could have been reached with less pain.
  7. The risk of oversimplification: clean frames like "only one at a time" and "risk budget" are easy to remember, but real decisions are not that simple. It is even ambiguous what counts as "one" gamble, and risk is hard to quantify. These frames are starting points for thinking, not formulas.

These critiques do not negate the value of the lessons. Rather, they are safeguards for applying the lessons more accurately. The key is to extract universal principles from retrospectives while re-verifying those principles in your own context. A good retrospective gives not answers but better questions, and the lessons come alive only the moment you throw those questions at your own project.

Conclusion — How to Manage Ambition

The reason Carmack's Quake retrospective still circulates today is that it is not a mere old story but shows a structure every ambitious project faces repeatedly.

To summarize:

  1. Only one big gamble at a time. Stacking several new things simultaneously multiplies risk and makes cause isolation impossible.
  2. Choose stable foundations. Save innovation for the core differentiation point, and fill the rest with boring, proven things.
  3. Control scope and make debt visible. Consciously tracking the debt that accompanies ambition lets you restore it.
  4. Technical decisions are people decisions. Without assessing the human cost of ambition, you can succeed technically yet lose the team.
  5. Have the discipline of shipping and iterating. Divide ambition across several versions and know how to stop and ship, so that ambition becomes reality.
  6. Draw lessons from retrospectives, but beware survivorship bias and the hero narrative, and re-verify in your own context.

In 2026, when AI generates code rapidly, the speed of building something has increased, but the judgment of what to build, what risks to take, and who pays the cost remains the job of people. The deepest lesson of Carmack's retrospective may be this: great technology comes from ambition, but a sustainable team comes from the restraint that manages that ambition.

The reason this lesson resonates so much is that it is not about a genius's extraordinary insight but about the ordinary traps everyone falls into. Most of us do not invent game engines like Carmack, but the temptation of "while we're at it, let's redo everything," the experience of scope creeping upward, and the moment ambition is billed as the team's overtime — almost everyone goes through these. That is why a thirty-year-old retrospective from a game company reads like our own sprint retrospective today.

In the end, engineering maturity shows not in the size of ambition but in how you handle it. To dream big, yet concentrate that dream in one place, stabilize the rest, care for people, and know how to stop and ship. This is the quiet advice Carmack's retrospective hands us across thirty years.

Before you start your next project, count just one thing: "how many big gambles are we carrying simultaneously right now." If that number is greater than one, healthy engineering begins with asking what can be reduced.

The desire to build something great and the desire to make it sustainable do not conflict. The bridge that connects the two is restraint.

Again, to emphasize: this article is a summary of general lessons based on public reporting and retrospectives, and contains no fictional dialogue put in any specific person's mouth.

References

Discuss on Twitter • View on GitHub