Technical debt
Technical debt is the future cost, effort, or risk created by technical choices or deferred work that make a system harder to change, maintain, or operate.
Lead Developer Career Guide
The future cost of maintaining or changing software resulting from expedient choices or unresolved technical issues.
- How it is used
- Helps lead developers balance timely delivery with code quality and organize maintenance work alongside features and bugs.
- How deep it goes
- Defines the cost and its tradeoff, then gives preventative and sprint-planning tactics; it does not specify a debt-measurement formula.
- Examples
- Uses a loan analogy and a homegrown client-side data-management component that substantially slowed feature development.
- What you can do after
- Practice/perform debt management by documenting decisions, prioritizing estimated fixes, and negotiating sprint capacity with the product team.
Read how Lead Developer Career Guide explains technical debt →
Architecture Modernization: Socio-technical alignment of software, strategy, and structure
Technical debt is the future cost and constraint created by choosing expedient implementation or maintenance decisions over more durable solutions.
- How it is used
- Frames architectural and organizational constraints in business terms so stakeholders can judge modernization investment.
- How deep it goes
- Explains a reinforcing cycle of declining system health and rising modernization cost, but stops short of implementation-level remediation.
- Examples
- Uses a financial-services modernization effort, legacy integrations, bolt-on tools, and research estimating substantial developer time lost to debt.
- What you can do after
- Evaluate modernization proposals, expose misleading quick fixes, and communicate their business benefits and required investment.
Think Like a Software Engineering Manager
Technical debt is the accumulated future cost of expedient technical decisions that make software harder to change or maintain.
- How it is used
- Uses technical debt to guide operational-excellence work, prioritization, service-health improvement, and communication with nontechnical partners.
- How deep it goes
- Defines causes, trade-offs, metrics, stakeholder communication, and reduction questions, but stops short of implementation detail.
- Examples
- Uses rising on-call workload and manual graph-database onboarding to show how debt affects teams, customers, costs, and reliability.
- What you can do after
- Apply it via design questions, quality measures, prioritized debt work, and concrete cost-and-impact discussions.
Read how Think Like a Software Engineering Manager explains technical debt →
Delivering Machine Learning Projects: From design to deployment
Technical debt is the future cost created by expedient technical decisions that increase maintenance, correction, or evolution effort.
- How it is used
- Frames maintenance and production support as deliberate work to reduce accumulated correction, troubleshooting, and evolution costs.
- How deep it goes
- Defines the performance gap and identifies logging, monitoring, algorithm obsolescence, governance, and support as concrete debt-management concerns.
- Examples
- Uses missing logs, absent alerts, outdated models, failed data flows, and unclear support responsibility as concrete debt examples.
- What you can do after
- Diagnose technical debt by checking instrumentation, comparing model performance, clarifying ownership, and planning remediation and failure response.
Read how Delivering Machine Learning Projects: From design to deployment explains technical debt →
Graph Neural Networks in Action
Technical debt is the future cost of design or implementation decisions that require later rework, workarounds, or replacement.
- How it is used
- Prevents avoidable rework while graph datasets, schemas, models, and data pipelines evolve.
- How deep it goes
- Defines causes and gives iterative testing and refactoring procedures, but stops short of quantifying debt or detailing migration strategies.
- Examples
- Uses candidate-referral data, schema constraints, graph queries, attribute checks, edge-label checks, relationship counts, and unique identifiers.
- What you can do after
- Diagnose technical debt with graph integrity tests and refactor schemas or pipelines through measured iterations.
Read how Graph Neural Networks in Action explains technical debt →
"Looks Good to Me"
The future maintenance and remediation cost created by accepting an expedient or suboptimal software decision.
- How it is used
- Frames code-review decisions about whether rework is warranted or expedient code should be accepted with future cost.
- How deep it goes
- Identifies difficult review scenarios and prevention practices, but stops short of defining remediation plans or measuring debt.
- Examples
- Uses oversized pull requests, architectural problems, unagreed tools, incomplete requirements, misunderstood requirements, and subtle bugs.
- What you can do after
- Diagnose/debug with it by spotting tough review issues and choosing between rework, delay, and knowingly accepting debt.
Think Like a CTO
Technical debt is the accumulated cost of choosing short-term technical solutions that make future software maintenance or change more difficult.
- How it is used
- Guides enterprise teams in recognizing, measuring, prioritizing, and repaying the maintenance cost of fast technical decisions.
- How deep it goes
- Explains causes, repayment allocation, measurement, backlog capture, and sprint practices, but stops short of implementation-level remediation.
- Examples
- Uses skipped vehicle maintenance, hardcoded values, client conditionals, and separate client repositories as concrete debt scenarios.
- What you can do after
- Operate a debt-management practice using code-quality tools, backlog entries, review checkpoints, repayment capacity, and extensible client-request designs.
Collaborative Software Design: How to facilitate domain modeling decisions
The future cost of deliberately choosing a less-than-ideal software design or implementation in order to deliver value sooner.
- How it is used
- Frames deliberate design compromises as obligations that teams should surface and manage during collaborative architectural decision-making.
- How deep it goes
- Defines deliberate debt, distinguishes it from implicit cruft, and outlines delivery and social consequences without detailing repayment procedures.
- Examples
- Uses inability to add functionality, slower production delivery, hacks, bugs, frustration, and communication breakdown as consequences.
- What you can do after
- Evaluate deliberate design trade-offs and make their risks and consequences explicit through collaborative modeling.
The Art of Code
Technical debt is the future cost of maintenance and change created by expedient technical choices or unresolved implementation deficiencies.
- How it is used
- Frames shortcuts and design decay as costs that shape maintainability, change, debugging, and engineering judgment.
- How deep it goes
- Explains causes, compounding consequences, and architectural responses, but does not provide a debt-measurement method or repayment workflow.
- Examples
- Uses AI-generated patch loops, outdated protocols, obsolete libraries, spaghetti code, layered architecture, modules, and hexagonal architecture.
- What you can do after
- Evaluate expedient technical choices and recognize when clearer boundaries are needed to keep software changeable and understandable.
PostgreSQL Mistakes and How to Avoid Them
Technical debt is the accumulated cost of delaying or choosing expedient implementations that make future changes or maintenance more difficult.
- How it is used
- Guides PostgreSQL teams toward early planning and intervention before performance, reliability, or scalability problems escalate.
- How deep it goes
- Explains preventive practices and inherited-database triage, but does not provide implementation-specific SQL or configuration examples.
- Examples
- Uses future bottleneck analysis, production-like staging, ecosystem tools, code reviews, and inherited-database assessment as practical examples.
- What you can do after
- Apply preventive planning, diagnosis, staged changes, monitoring, and incremental improvement to reduce PostgreSQL technical debt.
Read how PostgreSQL Mistakes and How to Avoid Them explains technical debt →
Related concepts
- refactoringaddressed by · Refactoring is the restructuring of existing software or code to change its internal organization and improve its design, typically while preserving externally observable behavior.
- pair programmingaddressed by · Pair programming is a software development practice in which two people collaborate on the same programming task, sharing implementation, review, or guidance responsibilities.
- code duplicationproduced by · Code duplication is the presence of equivalent or substantially similar source code or implementation logic in multiple locations within a software system.
- technical leadaddressed by · A technical lead is a software engineer who provides technical ownership, direction, coordination, and guidance for a team or project.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.