At QCon London 2026, Joy Ebertz, Principal Engineer at Imprint, presented a practical framework for prioritizing technical debt, arguing that in an era where AI tools are accelerating code production, the question is no longer how to eliminate tech debt, but which debt actually matters.
Ebertz, who has previously held Staff+ roles at Harness, Split, and Box, opened by challenging the perfectionist mindset that all tech debt must be resolved. She argued that having a perfect codebase is meaningless if the company goes under, and that the real goal is to write the best software possible for the situation at hand.
The core of the presentation was a six-question framework designed to help engineering teams evaluate and prioritize technical debt. The first question, “What is the cost if we don’t do anything?”, examines the breadth and depth of impact across developers and users, including cascading effects such as customer churn and developer attrition. Ebertz highlighted “ticking time bombs” as a particular category, distinguishing between scale problems that come with warning systems and security vulnerabilities where exploit probability is uncertain.
The second question What is the cost of fixing it?
addresses the cost of fixing the debt, including opportunity cost, training engineers on new systems, running dual systems during migration, and hidden surprises. Ebertz shared an example of a system migration where an entire feature was missed during the transition.
The third question Do we need to fix it the right way?
challenges whether a proper fix is even necessary, suggesting that an 80% solution at a fraction of the cost may be sufficient. She offered practical examples such as nightly database cleanup scripts, hard-coded limits, and monthly server restarts, noting that a one-hour hard-coded solution can sometimes accomplish what would take four weeks to build properly.
The remaining questions focus on timing, completion likelihood, and whether the project will actually improve the situation. On timing, Is now the right time?
, Ebertz encouraged teams to consider whether the system is getting worse or better on its own and whether new tools, particularly AI, might make the refactoring easier in the future.
On completion, Will we be able to get the project to the finish line?
, she shared a cautionary example of a PHP codebase that evolved through multiple framework iterations, from models to actions to “new actions” to “new new actions”, without ever completing a migration, leaving a growing problem.
On outcomes, Will a project actually make things better?
, she warned that teams often become so focused on the cons of the current solution that they forget its original pros, and recommended building in checkpoints to re-evaluate whether continuing a migration makes sense.
Ebertz also addressed how to build business cases for tech debt work, advocating for translating technical decisions into financial terms. Her approach involves calculating current costs, assessing whether they are increasing or decreasing, ideating multiple solutions, and comparing the incremental current cost against the incremental future cost plus the fixed implementation cost. She demonstrated this with a security patch example where a 5% chance of exploit multiplied by a large fine produces an expected cost that is straightforward to justify.
The presentation concluded with a discussion of AI’s impact on technical debt. Ebertz acknowledged that AI is producing more “slop”, lower quality code, at a faster rate than ever, but argued that the key question is whether it matters. She drew a distinction between debt that is harder to fix, such as data migrations, security vulnerabilities, and highly performant code, and debt that is easier to fix, such as walled-off components with clear boundaries and internal tools where minor bugs have low impact.
