⌘K
Change language Switch ThemeSign In
Narrow Mode
QCon London 2026: All Tech Debt is Not Created Equal ====================================================
!Image 4: InfoQ InfoQ @Daniel Curtis
One Sentence Summary
Joy Ebertz presents a pragmatic six-question framework for prioritizing technical debt, emphasizing financial justification and the strategic acceptance of 'good enough' solutions in the AI era.
Summary
At QCon London 2026, Principal Engineer Joy Ebertz challenged the traditional engineering mindset of total debt elimination, proposing instead a strategic framework for prioritization. As AI accelerates code production and potentially increases 'code slop,' the focus must shift from fixing everything to identifying which debt truly impacts the business. Her framework utilizes six critical questions to evaluate the cost of inaction, the feasibility of 80% solutions, and the likelihood of project completion. A key highlight is her method for building business cases by translating technical risks into financial terms—calculating expected costs based on probability and impact. Ultimately, she distinguishes between 'hard-to-fix' debt, like data migrations and security, and 'easy-to-fix' debt in isolated components, urging teams to focus their limited resources where they generate the most value.
Main Points
* 1. Prioritize technical debt by evaluating the 'cost of doing nothing' versus the 'cost of fixing'.Instead of seeking perfection, teams should analyze the breadth of impact on users and developers, identifying 'ticking time bombs' like security flaws while accepting manageable scale issues. * 2. Adopt '80% solutions' to address technical debt with minimal resource investment.Practical workarounds like nightly cleanup scripts or hard-coded limits can often solve problems in hours that would otherwise take weeks to refactor properly, preserving engineering bandwidth. * 3. Translate technical debt into financial terms to secure business buy-in for refactoring.By calculating the expected cost of risks—such as multiplying the probability of a security exploit by the potential fine—engineers can present a clear, data-driven justification to stakeholders. * 4. Assess the likelihood of project completion before initiating a major migration or refactor.Incomplete migrations lead to fragmented architectures (e.g., 'new new actions' traps); teams must ensure they have the momentum and resources to reach the finish line before starting. * 5. Distinguish between structural debt and 'slop' in the age of AI-generated code.AI produces lower-quality code faster, but debt in walled-off components or internal tools is often 'easy to fix' and less critical than debt involving data integrity or core performance.
Metadata
AI Score
84
Website infoq.com
Published At Today
Length 605 words (about 3 min)
Sign in to use highlight and note-taking features for a better reading experience. Sign in now
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.
!Image 5/filters:no_upscale()/news/2026/03/tech-debt-not-equal/en/resources/1qcon-techdebt1-1773696697759.png)
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.
!Image 6/filters:no_upscale()/news/2026/03/tech-debt-not-equal/en/resources/1qcontechdebt2-1773696697759.png)
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.
!Image 7: InfoQ InfoQ @Daniel Curtis
One Sentence Summary
Joy Ebertz presents a pragmatic six-question framework for prioritizing technical debt, emphasizing financial justification and the strategic acceptance of 'good enough' solutions in the AI era.
Summary
At QCon London 2026, Principal Engineer Joy Ebertz challenged the traditional engineering mindset of total debt elimination, proposing instead a strategic framework for prioritization. As AI accelerates code production and potentially increases 'code slop,' the focus must shift from fixing everything to identifying which debt truly impacts the business. Her framework utilizes six critical questions to evaluate the cost of inaction, the feasibility of 80% solutions, and the likelihood of project completion. A key highlight is her method for building business cases by translating technical risks into financial terms—calculating expected costs based on probability and impact. Ultimately, she distinguishes between 'hard-to-fix' debt, like data migrations and security, and 'easy-to-fix' debt in isolated components, urging teams to focus their limited resources where they generate the most value.
Main Points
* 1. Prioritize technical debt by evaluating the 'cost of doing nothing' versus the 'cost of fixing'.
Instead of seeking perfection, teams should analyze the breadth of impact on users and developers, identifying 'ticking time bombs' like security flaws while accepting manageable scale issues.
* 2. Adopt '80% solutions' to address technical debt with minimal resource investment.
Practical workarounds like nightly cleanup scripts or hard-coded limits can often solve problems in hours that would otherwise take weeks to refactor properly, preserving engineering bandwidth.
* 3. Translate technical debt into financial terms to secure business buy-in for refactoring.
By calculating the expected cost of risks—such as multiplying the probability of a security exploit by the potential fine—engineers can present a clear, data-driven justification to stakeholders.
* 4. Assess the likelihood of project completion before initiating a major migration or refactor.
Incomplete migrations lead to fragmented architectures (e.g., 'new new actions' traps); teams must ensure they have the momentum and resources to reach the finish line before starting.
* 5. Distinguish between structural debt and 'slop' in the age of AI-generated code.
AI produces lower-quality code faster, but debt in walled-off components or internal tools is often 'easy to fix' and less critical than debt involving data integrity or core performance.
Key Quotes
* Having a perfect codebase is meaningless if the company goes under; the real goal is to write the best software possible for the situation at hand. * A one-hour hard-coded solution can sometimes accomplish what would take four weeks to build properly. * Teams often become so focused on the cons of the current solution that they forget its original pros. * AI is producing more 'slop', lower quality code, at a faster rate than ever, but the key question is whether it matters. * The question is no longer how to eliminate tech debt, but which debt actually matters.
AI Score
84
Website infoq.com
Published At Today
Length 605 words (about 3 min)
Tags
Technical Debt
Engineering Management
Software Architecture
AI in Software Engineering
Prioritization Framework
Related Articles
* Choosing the Right Multi-Agent Architecture for AI applications, detailing their uses, tradeoffs, and performance to guide developers in choosing the right pattern.") * OpenAI Introduces Harness Engineering: Codex Agents Power Large‑Scale Software Development * Architecture in a Flow of AI-Augmented Change * Conversation: LLMs and the what/how loop * Where Architects Sit in the Era of AI to describe human-AI collaboration levels, and highlighting the extende...") * Build Hour: API & Codex * 4 Patterns of AI Native Development * Design-First Collaboration * Engineering Speed at Scale — Architectural Lessons from Sub-100-ms APIs * OpenClaw: The Viral AI Agent that Broke the Internet - Peter Steinberger | Lex Fridman Podcast #491 HomeArticlesPodcastsVideosTweets
QCon London 2026: All Tech Debt is Not Created Equal | Be... ===============