Priya Sharma
Every team I’ve ever worked with has said some version of the same thing: “We’ll clean it up after launch.” I’ve said it myself. And I’ve watched it age into the most expensive lie in game development.
Technical debt in games isn’t like technical debt in, say, a SaaS product. A web app with messy code still loads. A game with messy code starts to crack at the seams in ways that are uniquely catastrophic: physics interactions that only break on specific hardware, animation state machines that corrupt save files three months after ship, AI behaviors that work fine until you add one more enemy type and suddenly nothing works. The feedback loops are brutal and the costs are invisible until they’re not.
What most people don’t realize is that the debt doesn’t accumulate linearly. It compounds. And the compounding usually starts around the time you add your second system on top of your first.
Why Games Accumulate Debt Faster Than Other Software
Scope creep is the obvious answer, but it’s not the real one. Games accumulate debt fast because of prototyping culture. You build something quick and dirty to answer a design question. The design question gets answered. The dirty code stays. Someone else writes a system on top of it. Then another person writes something that depends on the second thing. By the time you have a full team, you’ve got architectural decisions being made by accident, not intention.
I’ve seen studios ship a full production level on top of prototype-quality camera code because no one wanted to be the person who said “we need to stop and rebuild this.” That camera code caused bugs from Alpha through certification. The fix took six weeks post-launch and broke three other systems. The original rebuild would have taken two weeks in pre-production.
There’s also the discipline problem. Junior developers (and sometimes senior ones) under crunch don’t write TODO comments. They write workarounds. Fast ones. That work right now, in this build, with these assets. The next person who touches that file is inheriting a ticking clock they don’t know about.
The Taxonomy That Actually Helps
| Debt Category | Characteristics | Impact Timeline | Action Priority |
|---|---|---|---|
| Rot | Fragile, poorly documented, currently working | Hurts when touched | Queue for planned refactor |
| Friction | Slows daily development (slow builds, broken pipelines) | Cumulative cost every sprint | High ROI on fixing |
| Liability | Actively wrong, will cause incidents | Urgent/blocking | Immediate board placement |
Not all technical debt is the same, and treating it like a monolith is why most teams either ignore it completely or try to boil the ocean. I’ve found it useful to split debt into three rough categories based on urgency and blast radius.
The first category is rot: code that’s fragile, poorly documented, and currently working. It doesn’t hurt today. It will hurt when you touch it. You know the kind, a save serializer that nobody remembers writing, held together by implicit assumptions about load order.
The second is friction: debt that costs you time every single day. Slow build times, a broken asset pipeline that requires three manual steps before iteration, a physics tick that makes profiling sessions take twice as long. This is the category most producers underestimate. A build pipeline that takes 40 minutes instead of 15 adds up to roughly 300 developer-hours lost per month on a 20-person team. That’s a real number. Friction debt has a clear ROI on fixing.
The third is liability: debt that is actively wrong and will cause an incident. A memory leak that only triggers on PS5 in a specific gameplay scenario. An AI pathfinding implementation that corrupts the navmesh when streaming zones at a certain distance. This goes on the board immediately, not next sprint.
Once you can categorize debt this way, prioritization becomes a real conversation instead of a vague “we should probably refactor that someday” discussion in a retrospective.
How to Actually Manage It (Not Just Acknowledge It)
Codecks -- Game Development Project Management Tool · Gamefromscratch on YouTube
The most effective thing I’ve done as a producer is make debt visible. Not by adding a “tech debt sprint” every quarter (that doesn’t work, I’ll explain why in a second), but by creating a living document the team actually looks at.
In practice, this means a dedicated backlog column in whatever project management tool you’re using. Jira, Shortcut (formerly Clubhouse), Hack’n’Plan, it doesn’t matter. What matters is that engineers can file debt tickets the same way they file bugs, with a category tag (rot, friction, liability), an estimated blast radius, and a rough fix cost. Not precise, rough. Two hours, two days, two weeks. That’s enough to triage.
The “tech debt sprint” model fails because it creates the illusion of a dedicated window while actually training the team that debt is a problem you deal with periodically, not continuously. Teams that batch debt into quarterly cleanups end up with the last six weeks before the cleanup being a lawless period where everyone knows the refactor is coming anyway, so why bother being careful now.
What works better: a standing allocation. Every sprint, 15-20% of engineering capacity goes to debt reduction, with the engineering lead picking the items. Not the producer. The engineer closest to the code has to have real authority over what gets cleaned up, or the system becomes performative. Producers track that the allocation is being protected. Engineers decide how it’s spent.
One more thing that’s underused: the “stop adding to it” intervention. Sometimes the most productive thing a producer can do is freeze a system. Mark it in Jira as “no new features until refactored.” It feels bureaucratic but it works. It stops the bleeding while you queue up the fix.
Tools That Help
Sources
- Nemuel Sereti
- tools (built into Rider
- in the editor plus SonarQube is a solid combination if you want automated flaggi
For tracking, I’d recommend anything that lets you link debt tickets to the features they affect. Being able to see “this inventory system has four open debt items” before you spec new inventory features is genuinely useful. Jira’s issue linking does this fine. So does Linear, which I prefer for smaller teams under 30 people because it’s faster and less ceremonially heavy.
For the engineering side, JetBrains’ code analysis tools (built into Rider, which is what most Unity shops use) surface a lot of rot automatically. It’s not a substitute for human judgment, but it catches things. For Unreal teams, the built-in code analysis in the editor plus SonarQube is a solid combination if you want automated flagging.
If you want to go deeper on the structural side, Michael Nygard’s Release It! isn’t a game dev book but it’s one of the best things I’ve ever read about how systems fail. Pair it with The Art of Game Design by Jesse Schell for context on why game systems are structurally different from enterprise software. Both are on the shorter end for technical books and both are worth owning physically.
For online learning, the Game Producers Masterclass on Udemy (Patrick Lipo’s course) has solid coverage of sprint planning that touches on capacity allocation for maintenance work. Not specifically about debt, but useful framing.
Photo: Nemuel Sereti via Pexels
