Also called: Code Debt, Design Debt, Architectural Debt, Test Debt, Documentation Debt, and Refactoring Debt
See also: Continuous Improvement, Bugs, Continuous Delivery
Relevant metrics: Code Quality, Test Coverage, Maintainability, Reliability, and Deployment Frequency
What Is Technical Debt?
Technical debt is the additional future work created when teams choose a quicker or simpler solution today instead of the cleaner, longer‑term option. The term was introduced by Ward Cunningham, who compared rushed code to a monetary loan: you gain short‑term speed but repay the loan later with “interest” in the form of extra maintenance and risk.
Deliberate vs. Inadvertent Debt (Martin Fowler’s Technical‑Debt Quadrant)
Martin Fowler extended Ward Cunningham’s metaphor by mapping debt into four quadrants using two questions: Was the debt taken on deliberately or by accident? and Was that choice prudent or reckless?
Prudent – the team believed it was the best trade‑off | Reckless – the team ignored known risks or good practice | |
---|---|---|
Deliberate | Strategic debt – a conscious shortcut with a clear business return and an explicit pay‑back plan. Example: shipping an MVP with a temporary admin tool scheduled for rewrite next quarter. | Cruft‑making debt – conscious shortcuts without a plan. Example: hard‑coding business rules to meet an arbitrary date and then moving on. |
Inadvertent | Discovery debt – decisions that later prove sub‑optimal as the team learns more. Example: refactoring after real‑world load exposes a performance bottleneck. | Accidental debt – poor solutions born of inexperience or missing context. Example: copy‑and‑paste code that hides security flaws. |
Key takeaway: Not all debt is harmful. Teams should focus on turning prudent, deliberate debt into knowledge and value, while quickly surfacing and reducing reckless debt.
Working with the quadrant
- Classify debt items as they surface. During backlog grooming, tag each debt ticket with its quadrant. This keeps the discussion factual and action‑oriented.
- Match actions to quadrant.
Strategic debt → track in the product roadmap with a repayment date.
Discovery debt → schedule incremental refactors as knowledge improves.
Cruft‑making debt → raise a risk flag; negotiate either scope cut or more time.
Accidental debt → pair senior engineers with the code owner and add automated tests. - Review quadrant distribution. A healthy code base should trend toward prudent categories. A spike in reckless debt can indicate a cultural or process issue.
- Attach metrics. Combine quadrant tags with defect density or cycle‑time reports to reveal the cost of each debt class.
- Communicate in business terms. Translate each quadrant’s impact into delivery delay, revenue risk, or compliance exposure so non‑technical stakeholders can prioritise.
Using the quadrant consistently builds a shared vocabulary between product, engineering, and leadership. It turns the abstract idea of “technical debt” into a concrete, trackable element of delivery health.
Why Technical Debt Happens
Technical debt does not arise by accident; it accumulates when common pressures, gaps, and trade‑offs nudge teams toward shortcuts. Recognising these root causes early is the first step to preventing unnecessary interest on your code base.
Time‑to‑market pressure and competitive deadlines
To capture market share quickly, product teams sometimes ship a minimal version and promise to “clean it up later.” This deliberate technical debt can be prudent when it is repaid soon after release, but if the backlog grows unchecked the interest compounds, slowing every future software‑development cycle.
Skill or knowledge gaps inside the team
When engineers lack domain expertise or experience with a particular language or framework, they may implement work‑arounds that appear functional yet hide complexity. This inadvertent technical debt resurfaces as defects, rework, and longer cycle time.
Legacy frameworks or outdated dependencies
Running on end‑of‑life frameworks or libraries with known vulnerabilities creates architecture and security debt. Upgrades are often deferred because they seem “non‑functional,” yet each delay increases the eventual migration cost and operational risk.
Incomplete test coverage that discourages refactoring
Without a robust suite of unit and integration tests, developers hesitate to modify brittle code. The resulting fear of change acts as a barrier to paying down existing technical debt and often produces still more debt.
Shifting product requirements that force quick pivots
Rapid changes in market or stakeholder priorities can invalidate earlier design decisions. Each pivot introduces shortcuts—feature flags, duplicated modules, quick patches—that become long‑lived debt if not cleaned up during the next sprint.
Technical Debt Costs, Risks, and Cost of Delay
Technical debt imposes more than code‑level headaches; it erodes delivery speed, product quality, security posture, operational stability, and team engagement. Each hidden shortcut grows like compound interest, expanding the gap between how quickly you could ship value and how long it actually takes—a gap economists call cost of delay.
When business stakeholders ask, “Why tackle technical debt now?” link the conversation to measurable outcomes: slower feature throughput, revenue lost during outages, rising defect backlogs, and employee churn. These outcomes connect directly to profit‑and‑loss statements and customer retention metrics, turning an abstract engineering concept into a concrete business risk.
Impact Dimension | Immediate Symptom | Long‑Term Consequence |
---|---|---|
Delivery speed | More rework, longer code reviews, sluggish build pipelines | Cost of delay grows; market windows close before features launch |
Product quality | Higher defect density and escaped bugs | Declining user satisfaction and increased support costs |
Security posture | Unpatched libraries and misconfigurations | Breach risk, regulatory fines, and reputational damage |
Operational uptime | Incident frequency and mean time to restore creep upward | Multi‑day outages like the 2024 airline crash, triggering direct revenue loss |
Team morale | Engineers spend sprints firefighting instead of innovating | Talent attrition, hiring overhead, and slower onboarding |
Consider delivery speed: every extra day spent disentangling legacy code pushes feature revenue into the future. Multiply that delay by high‑value releases and the annualized cost rivals headline R&D budgets. Add quality debt—bugs that slip to production—and support teams escalate burn as generous SLA credits eat margins.
Security adds another layer. According to Sonatype’s State of the Software Supply Chain 2024, the median time to patch critical open‑source vulnerabilities now exceeds 500 days. The longer a flaw lingers, the higher the breach probability and the steeper the clean‑up bill.
Operational outages convert hidden debt into headline news. The 2024 airline system failure cost an estimated USD 500 million in refunds and lost bookings. Similar events erode brand trust faster than any marketing campaign can rebuild it.
Finally, people costs appear on turnover reports. Developers trapped in high‑debt code bases report lower job satisfaction, and replacing them can cost 50–100 % of annual salary. Healthy engineering culture hinges on a code base that welcomes change rather than punishes it.
Addressing technical debt is therefore not optional housekeeping; it is strategic risk management that preserves velocity, revenue, and resilience.
Common Types of Technical Debt
Technical debt is multidimensional; it sits in code, architecture, tests, security, and even team process. Each dimension can land in any quadrant of Martin Fowler’s model—strategic, discovery, cruft‑making, or accidental—depending on intent and prudence. Mapping the layer and the quadrant clarifies both urgency and remediation strategy.
Code Debt
Code debt lives in naming shortcuts, tangled logic, and duplicated functions. A quick inline patch added hours before a launch is strategic, deliberate, provided there is a follow‑up refactor ticket. Copy‑and‑paste blocks added by a new hire who did not know better are accidental, reckless. The same layer requires different treatments: scheduled cleanup for the strategic debt, paired mentoring and test coverage for the accidental debt.
Architecture Debt
Architecture debt emerges when core patterns—service boundaries, data flow, deployment topology—no longer match current scale or requirements. The team might accept strategic architecture debt by colocating two services to hit a go‑live date, planning a split next quarter. By contrast, ignoring a known monolith bottleneck year after year drifts into cruft‑making debt, raising cycle time and outage risk.
Test Debt
Test debt appears as missing unit tests, brittle integration scenarios, or flaky end‑to‑end suites. During discovery debt, tests fall behind feature pace until the team realises coverage gaps block refactoring. If leadership knowingly deprioritises test automation in every sprint, that choice migrates toward reckless, cruft‑making debt, leaving the code base change‑averse.
Security Debt
Security debt accumulates through unpatched libraries, permissive configurations, or stale secrets. Teams sometimes make a prudent, deliberate trade‑off—shipping a feature while tracking a dependency update for the next release. Yet postponing security patches indefinitely is reckless and shifts the item into the quadrant most likely to trigger fines or brand damage.
Process Debt
Process debt hides in manual release steps, undocumented runbooks, or siloed approvals. Early‑stage startups accept lightweight process by design—strategic debt that keeps focus on product–market fit. As headcount grows, failing to automate or document becomes accidental or cruft‑making debt that slows every incident response.
By classifying each debt item by layer and quadrant, teams decide whether to repay immediately, schedule incremental work, or accept the interest for a time‑boxed period.
Measuring Technical Debt
What you measure gets managed. Selecting clear, actionable indicators helps teams focus their improvement work and demonstrate progress to stakeholders. Effective measurement spans two layers:
- Direct code and process metrics that reveal the immediate cost of remediation.
- Indirect or lagging indicators that highlight the broader business impact of excessive debt.
Direct Metrics
Classic quantitative measures expose the size and cost of debt within the code base. The table below summarises four widely used metrics and how to capture them.
Metric | Definition | How to capture |
---|---|---|
Technical debt ratio | (Remediation cost ÷ Development cost) × 100 %. A ratio below 5 % is a common goal. | Static‑analysis tools (e.g., SonarQube). |
Mean time to restore (MTTR) | Average time to recover from a production failure. A rising MTTR signals hidden architectural debt. | Incident‑management logs. |
Defect density | Confirmed defects per thousand lines of code (KLOC). | Issue tracker plus code‑analysis scripts. |
Cycle time | Median time from code commit to production. Longer cycle time, especially for small changes, often correlates with debt build‑up. | CI/CD analytics. |
Tracking these values sprint over sprint surfaces trends early, enabling data‑driven discussions about when to allocate remediation capacity.
Indirect or Lagging Indicators
Direct metrics may not capture the full organisational cost. Complement them with broader signals that debt is hindering agility or customer experience:
- Number and severity of major incidents. An uptick in Sev‑1 or Sev‑2 outages can indicate fragile architecture and hidden coupling.
- Time to market for new features. If months separate the decision to build from customer launch, debt may be the primary drag on throughput.
- Server response time and performance regressions. Older, inefficient code paths increase infrastructure spend and degrade user satisfaction.
- On‑call load and pager fatigue. High alert volume shifts engineers from proactive work to firefighting.
- Innovation rate. Fewer experiments or A/B tests suggest capacity is spent stabilising rather than learning.
Debt and Agility
In an agile context, the most significant risk of unchecked technical debt is the loss of pivot capacity. When market feedback requires a new direction, teams with lean, well‑tested code can adapt within days. Teams weighed down by complex dependencies and brittle tests struggle to change scope without escalating effort, turning sprints into marathons.
Choosing the Right Metrics
Avoid tracking every metric; pick one or two direct metrics (e.g., debt ratio and cycle time) and one indirect indicator (e.g., incident count). Review them in sprint retrospectives alongside Martin Fowler’s quadrant tags. When a metric improves, acknowledge progress; when it stagnates, investigate root causes and adjust the backlog.
By combining precise code‑level measures with business‑facing indicators, you ensure that remediation work stays visible and aligned with product goals.
Technical Debt Remediation Strategies
Reducing technical debt is an ongoing programme, not a one‑time clean‑up. The strategies below show how to surface, rank, and retire debt without derailing feature delivery.
Visible Debt Registry
Log every shortcut as a backlog item so it competes transparently with user stories. Capture quadrant, impact, and effort on the ticket itself.
Example ticket
Title:[Debt] Replace ad‑hoc CSV parser in payment‑service
Quadrant: Discovery / Prudent
Impact: Nightly reconciliation delayed 4 h; risk of data corruption
Estimate: L
A queryable registry lets product managers weigh cost of delay against roadmap commitments.
Cost of Delay–Risk Alignment
Cost of Delay (CoD) answers the question “If we do nothing for a week, how much value do we lose?” Risk considers “If this debt item explodes, how bad is the blast radius?” By scoring both dimensions you create a transparent, repeatable way to decide what to fix first.
Quantify Cost of Delay
- Translate value to currency or proxy metrics. Daily subscription revenue, active‑user growth, or churn reduction are common.
- Estimate days blocked. How long will an unresolved debt item postpone a feature that drives that value?
- Compute CoD:
daily value × days blocked
.
Example: An overdue database index is slowing a revenue‑generating search feature by two weeks. With $15 000 in daily search‑driven conversions, CoD ≈ $210 000.
Score Risk Severity
Assign a 1‑to‑5 score on two factors: probability of failure and impact if failure occurs (financial, reputational, compliance). Multiply them for a composite risk number.
Example: An unpatched OpenSSL CVE with public exploits may carry probability 4 and impact 5 → risk score 20 (critical).
Prioritise with a 2 × 2 Matrix or WSJF
Plot CoD on the vertical axis and risk on the horizontal. Items in the top‑right (high CoD, high risk) move to the next sprint. For larger backlogs use Weighted Shortest Job First (WSJF):
WSJF = (CoD × Risk) ÷ Estimated effort
A one‑day patch for the critical OpenSSL CVE ($0 CoD but risk 20) still outranks a three‑day refactor with CoD $150 000 and risk 4.
Low Risk (≤ 6) | High Risk (≥ 15) | |
---|---|---|
Low CoD | Rename legacy variables in UI service | Upgrade test runner to latest LTS |
High CoD | Migrate billing rate table to NoSQL | Patch critical OpenSSL CVE in payment gateway |
Facilitate a CoD‑Risk Workshop
- Gather product, engineering, and security leads.
- Review the debt registry; for each ticket, annotate CoD and risk scores.
- Calculate WSJF or place the ticket on the matrix.
- Adjust scores after debate; seek consensus, not precision.
- Pull the highest‑priority debt items into the next sprint.
Link Back to Fowler’s Quadrants
High‑risk, high‑CoD debt is often cruft‑making—shortcuts taken with full knowledge but no plan. Prudent strategic debt tends to sit in the low‑risk, high‑CoD quadrant; teams accept it temporarily but set a near‑term repayment date to prevent drift.
Embedding CoD‑risk analysis into sprint planning keeps focus on business impact, ensuring remediation efforts protect both revenue and resilience.
Reserved Remediation Capacity
Reserve 10–20 % of every iteration for technical debt tickets. Some teams visualise this as a dedicated “TechDebt” swim‑lane on the Kanban board; others hard‑cap story‑points (e.g., 8 of 40 per sprint). Velocity may dip briefly but stabilises as debt ratio falls.
Boy‑Scout Rule in Daily Coding
The Boy‑Scout Rule—“leave the campground cleaner than you found it”—turns everyday commits into micro‑refactors that steadily retire technical debt.
Let’s look at a few examples of how you could integrate such principles into your daily work.
- Pull‑request templates. Add a checkbox: “Improved at least one touched area (naming, duplication, tests)?”.
- Code‑review rubric. Reviewers reward small clean‑ups with quick approvals or shout‑outs in Slack.
- Branch naming conventions. Prefix branches with
scout/
when a change is primarily hygiene; this feeds dashboards.
You could also introduce metrics that celebrate small technical debt wins, such as:
- Lines of dead code removed per sprint—shrinks attack surface.
- Cyclomatic complexity delta—should trend down or remain flat despite feature growth.
- Scout commits per engineer—signals cultural adoption.
Scout changes commonly eliminate discovery or accidental debt before it matures into cruft‑making debt.
Dedicated Refactoring Sprints
Some debt clusters are too entrenched for scout‑level fixes. Dedicated refactoring sprints carve out one or two full iterations where the sole backlog consists of high‑interest debt stories.
When to schedule a refactoring sprint
- A component’s change‑failure rate exceeds 25 % for three consecutive releases.
- Upcoming roadmap items require structural changes the present design cannot support.
- Median cycle time has doubled over six months despite stable team size.
Planning checklist
- Define a measurable outcome. Example: “Split user‑service into read/write APIs with p95 latency < 200 ms.”
- Snapshot baseline metrics. Record cycle time, defect density, MTTR, and latency.
- Slice the work. Break the debt cluster into small, demo‑able stories (e.g., extract domain models, introduce service mesh sidecar).
- Secure stakeholder sign‑off. Agree on a temporary feature freeze and communicate expected gains.
Refactoring sprints focus on cruft‑making debt or long‑ignored strategic debt before it snowballs into outages and lost revenue.
Test‑Driven Debt Reduction
Before touching high‑debt code, surround it with tests. One team generating 200 approval tests for JSON APIs reduced regression defects to near zero and tackled subsequent clean‑up with confidence. Each new test shortens the feedback loop and preserves the ability to pivot.
Together these strategies convert technical debt from silent drag into a visible, managed variable that leadership can budget and track.
Prevention Guidelines
A preventive mindset ensures debt never accumulates faster than it can be repaid. It begins with shared coding standards and rigorous code reviews. Clear guidelines on naming, testing, and architectural patterns act as guardrails, while structured reviews supply the social proof that small issues—duplicated logic, missing tests—are caught before they mature into accidental debt.
Fast‑feedback pipelines are the next defence. By maintaining continuous integration (CI) that builds, tests, and deploys on every commit, teams surface integration conflicts within minutes instead of days. A green‑light CI culture also lowers the fear of refactoring, because engineers gain immediate confirmation their scout‑level clean‑ups did no harm.
Dependencies can become invisible liabilities. Automating dependency‑update alerts keeps libraries current and patches known vulnerabilities quickly, curbing the rise of reckless security debt. Pair automated pull‑request tools with a weekly “dependency bump” slot on the kanban board so updates do not languish.
Debt hides in architecture, too. Schedule quarterly architecture or quality audits to compare the current system against intentional design. Use metrics from the measurement section—cycle time, defect density, MTTR—to flag components drifting toward the cruft‑making quadrant.
Finally, prevention is cultural. Educating stakeholders—product owners, designers, even finance—about the compounding cost of unmanaged debt secures the time and budget needed for remediation. When everyone recognises that sustainable velocity is a competitive advantage, prevention becomes part of normal planning rather than an after‑hours passion project.
Technical Debt Checklist
Before marking a shortcut as “acceptable,” run through this ten‑point checklist. It ensures each debt item is owned, sized, funded, and guarded by tests so that interest never compounds silently.
- Debt item recorded in backlog with clear owner.
- Impact assessed (delivery speed, defects, security, cost).
- Estimated remediation hours and resources.
- Test coverage available or planned.
- Business case accepted by product and engineering leads.
- Capacity allocated in sprint or roadmap.
- Refactoring completed and peer‑reviewed.
- Metrics updated to confirm reduction.
- Lessons captured in retro.
- Preventive guardrail added (lint, policy, automation).
Revisit this checklist during sprint retrospectives and quarterly planning. As the code base and team evolve, adjust thresholds and guardrails to keep technical debt within prudent, strategic bounds.
Frequently Asked Questions
What is meant by technical debt?
Technical debt is the future rework and risk incurred when a team opts for a faster, less‑optimal solution today. Like financial debt, it accumulates interest—slower delivery, more defects—until repaid through refactoring or redesign.
What is a technical debt in Scrum?
In Scrum, technical debt is any incomplete work, shortcut, or quality compromise that violates the team’s Definition of Done. It reduces the increment’s shippable quality and must be addressed in future sprints to maintain velocity.
How bad is technical debt?
Unchecked debt can double cycle time, increase incident frequency, and limit a company’s ability to pivot. A technical debt ratio above 10 % or a rising trend in mean time to restore often signals “bad” debt that needs immediate attention.
Who pays for technical debt?
Ultimately the organisation pays—through higher engineering costs, delayed revenue, or lost customers. In budgeting terms, remediation time comes out of the same capacity that could build new features, so product and engineering share the bill.
Why avoid technical debt?
Avoiding or promptly repaying debt preserves delivery speed, system reliability, and developer morale. It also lowers the cost of future pivots, making the business more responsive to market change.
How do you fix technical debt?
Fixing debt involves cataloguing items in a debt registry, prioritising with a cost‑of‑delay–risk matrix, allocating sprint capacity for remediation, and safeguarding changes with automated tests.
What is a good technical debt?
Good—or strategic—debt is deliberate, prudent, and tied to a clear learning or market opportunity. It comes with a defined pay‑back plan and a near‑term timeline for remediation.
What is the difference between a bug and technical debt?
A bug is a defect that causes incorrect behaviour; technical debt is latent complexity that increases the likelihood or cost of defects. Debt is about code quality and maintainability, whereas a bug is about functional correctness.
Is UX debt the same as technical debt?
UX debt refers to usability shortcomings accumulated over time. While the causes differ—UX debt often stems from rushed design—both forms create friction for users and developers and require remediation to restore product quality.
How do you visualize technical debt?
Teams use dashboards showing debt ratio, cycle time, and incident trends; architecture diagrams highlighting high‑debt modules; and cost‑of‑delay–risk matrices to visualise priority.
What is the wall of technical debt?
The “wall of technical debt” is a Kanban or physical board where teams display outstanding debt items. Making debt visible helps stakeholders grasp its scale and supports transparent prioritisation.
Examples
Microsoft
Microsoft has implemented a technical debt reduction program to help reduce the amount of technical debt in their products. This program includes a set of processes and tools to help identify and prioritize technical debt, as well as a set of metrics to measure progress. Microsoft also has a team dedicated to managing technical debt, which works with product teams to ensure that technical debt is managed and reduced.
Amazon
Amazon has implemented a technical debt management system to help reduce the amount of technical debt in their products. This system includes a set of processes and tools to help identify and prioritize technical debt, as well as a set of metrics to measure progress. Amazon also has a team dedicated to managing technical debt, which works with product teams to ensure that technical debt is managed and reduced.
Google has implemented a technical debt management system to help reduce the amount of technical debt in their products. This system includes a set of processes and tools to help identify and prioritize technical debt, as well as a set of metrics to measure progress. Google also has a team dedicated to managing technical debt, which works with product teams to ensure that technical debt is managed and reduced.
-
What is the cost of not addressing the technical debt?
Hint The cost of not addressing the technical debt can include increased development time, increased maintenance costs, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the project timeline?
Hint The potential impact of the technical debt on the project timeline can include delays in meeting deadlines, increased development time, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the project budget?
Hint The potential impact of the technical debt on the project budget can include increased development costs, increased maintenance costs, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the quality of the product?
Hint The potential impact of the technical debt on the quality of the product can include decreased reliability, decreased usability, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the user experience?
Hint The potential impact of the technical debt on the user experience can include decreased usability, decreased reliability, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the maintainability of the codebase?
Hint The potential impact of the technical debt on the maintainability of the codebase can include increased development time, increased maintenance costs, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the scalability of the product?
Hint The potential impact of the technical debt on the scalability of the product can include decreased performance, decreased reliability, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the security of the product?
Hint The potential impact of the technical debt on the security of the product can include increased vulnerability to attack, decreased reliability, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the performance of the product?
Hint The potential impact of the technical debt on the performance of the product can include decreased speed, decreased reliability, and decreased customer satisfaction. -
What is the potential impact of the technical debt on the team morale?
Hint The potential impact of the technical debt on the team morale can include decreased motivation, decreased productivity, and decreased customer satisfaction.
You might also be interested in reading up on:
- Martin Fowler @martinfowler
- Kevlin Henney @KevlinHenney
- Sandi Metz @sandimetz
- Uncle Bob Martin @unclebobmartin
- Michael Feathers @mfeathers
- Improving the Design of Existing Code by Martin Fowler, Refactoring (1999)
- Technical Debt Quadrant by Martin Fowler (2011)
- Strategies for Software Development Organizations by Chris Sterling, Managing Technical Debt (2013)
- An Introduction by Philippe Kruchten, The Rational Unified Process (2003)
- Management, Measurement, and Estimation by Tom DeMarco, Controlling Software Projects (1982)
- State of the Software Supply Chain 2024 by Sonatype Research Team at Sonatype
- The State of Technical Debt in the US 2024 by Forrester Research at Forrester
- Airline’s Legacy IT Crash Costs $500 Million by Reuters Staff at Reuters
- Technology Radar Vol. 30 by Thoughtworks Technology Advisory Board at Thoughtworks
- Technical Debt Quadrant by Martin Fowler at martinfowler.com
- Ward Cunningham on the Technical-Debt Metaphor (OOPSLA 1992 Experience Report) by Ward Cunningham at ACM OOPSLA
- Managing Technical Debt: Reducing Friction in Software Development by Philippe Kruchten, Robert Nord, Ipek Ozkaya at Addison-Wesley Professional
- Towards a Definition of Technical Debt by Philippe Kruchten, Robert Nord, Ipek Ozkaya at Carnegie Mellon University / IEEE
- Technical Debt – Ten Years Later by Steve McConnell at Construx Software
- What Is Technical Debt? by Atlassian Team at Atlassian
- Technical Debt and the Technical-Debt Ratio by SonarSource Docs Team at SonarSource
Want to learn more?
Receive a hand picked list of the best reads on building products that matter every week. Curated by Anders Toxboe. Published every Tuesday.
No spam! Unsubscribe with a single click at any time.
Community events
Product Loop
Product Loop provides an opportunity for Product professionals and their peers to exchange ideas and experiences about Product Design, Development and Management, Business Modelling, Metrics, User Experience and all the other things that get us excited.
Join our communityMade with in Copenhagen, Denmark
Want to learn more about about good product development, then browse our product playbooks.