Who This Book Is For

This book delves into the details of Technical Debt, but it was written to be accessible to a broad audience including developers, architects, and managers.

Software Developers

Avoid technical debt in the design and implementation of your system in every stage and aspect of the software licecycle.

Engineering Managers

Learn how your team's dynamics creates Technical Debt, how to detect it and plan for its reduction in your roadmap.


Discover what Technical Debt is, and learn how you can avoid it throughout your career, either as a developer or a manager.

Technical Debt in Practice cover

About The Book

This book is essential reading for any programmer, manager, or architect who wants to design software that will last and be healthy for years.

Learn From Experts

Tech lead at Twitter, AWS, researchers at Carnegie Mellon's Software Engineering Institute: the authors have lived the pain of Technical Debt.

Concrete Real-World Examples

Every aspect of the book is illustrated with a real-world example.

Clear and Actionable Advice

Like financial debt, Technical Debt is often a necessity, and is only bad when used in excess. Learn how to detect your debt, decide when to pay it down, and have an actional plan to reduce it over time.

Buy now on Amazon Buy now at MIT Press

Chapters We've Covered

Technical Debt impacts various aspects of the software development process. Our goal is to dedicate one chapter to each major aspect.

Book organization fishbone diagram showing causes of TD

Chapter 1 What is Technical Debt?

Learn what is technical debt, the well-known metaphor and the structure of the book.

Chapter 2The Importance of Technical Debt

Go beyond the metaphor. Technical Debt is often necessary but must not be used in excess. This chapter explains why Technical Debt can be good and what you should do about it.

Chapter 3 Requirements Debt

We begin by explaining how shortcuts in understanding product requirements leads to requirements debt. We seed the idea that successful software is about moving from requirements to released feature, quickly.

Chapter 4 Design and Architecture Debt

Architecture debt is the most costly and pernicious form of debt. We show you how to detect it, quantify it, and make the business case for paying it through refactoring.

Chapter 5 Implementation Debt

How your technical decisions on software implementation create technical debt. We discuss what language patterns to look for, why they create Technical Debt and how to avoid them.

Chapter 6 Testing Debt

How testing (or the lack of) introduces Technical Debt. We explain what should you be testing in your application, what are the acceptable levels of testing and how to enforce it and reduce Technical Debt.

Chapter 7 Deployment Debt

The rise of the DevOps culture and the move to the cloud created new tools that simplify application deployment. But using bad deployment and operations practices slows you down and could severely impact your business.

Chapter 8 Documentation Debt

Identifying and managing Technical Debt requires careful, yet efficient, documentation. We explain how to find shortcomings in documentation and how to implement cost-effective practices to prevent these problems.

Chapter 9 Technical Debt in Machine Learning

Increasingly systems are relying on machine learning. These system functions, like everything else in software, can accumulate debt.

Chapter 10 Team Management and Technical Debt

Software is written by people, organized into teams. In practice the structure and communication patterns of these teams can often be sub-optimal. We show you anti-patterns to watch for in your project and describe strategies for fixing them.

Chapter 11 Making the Business Case

Tecnical Debt is an effective metapor for communicating the importance of software maintenance to business stakeholders. We outline some simple approaches for getting management buy-in for the problem of Tecnical Debt.

Chapter 12 Conclusion

Summarizes the outcomes of the book with a set of tangible takeaways.

Case Studies

We draw on several real-world software systems and explain how those systems dealt with Technical Debt.

The Atacama Large Millimetre Array

The Atacama Large Millimetre/Submillimetre Array (ALMA) is a set of 66 radio dishes in the high Chilean desert, run by the ALMA science foundation (an international partnership of national science foundations). As with most large, billion dollar science projects, planning for the telescope began decades before science operations started in 2013. We outline the technical debt challenges ALMA faced in design, construction, and now operations.


Brightsquid is a software company based in Calgary, Canada, that makes secure communications solutions for the healthcare industry. The company has been in business for more than a decade and has been developing and evolving their core Platform continuously over that time. Like most long-lived software, their Platform has accumulated considerable technical debt. Brightsquid’s developers felt this, but they had no way of identifying this debt, measuring its impact, and determining if it would be worth refactoring.


Twitter is a world-leading social networking platform. We describe some of the scaling challenges Twitter faced in its early incarnation. In particular, through this case-study, we discuss how the company handled its growth when the underlying software architecture was not designed to handled the increase of load. We discuss how Technical Debt hit the company in its early days, from the use of a custom stack (custom form of the Ruby runtime or Ruby on Rails framework), relying on relational databases and the pain of scaling a monolithic application.

A Safety-Critical System

This case-study is about a safety-critical system, which is one used on military, avionics or nuclear systems and where life or millions of dollars can be at stake. The particular software we are considering was written in C and performs critical operations for a satellite-based positioning system. Failure of this software might impact boats, planes or trucks (failure to get location and directions, blocking hundreds of vehicles).

Experts We Interviewed

We interviewed software engineers that experienced technical debt and connected their experience throughout the book.

Marco Bartolini

Marco Bartolini is the lead software architect at the Square Kilometre Array, working to build the world's largest radio telescope. Marco explains some of the challenges building a long-lived, highly complex set of scientific software systems, and managing the process to avoid inadvertent technical debt.

Julien Danjou

Julien Danjou is the founder of mergify, a well-known Python developer and the author of the books Serious Python and The Hacker's Guide to Scaling Python. He shares his stories on technical debt, how he found it and reduced it.

Nicolas Devillard

Nicolas Devillard is a software engineer with experience in image processing, digital security, and embedded systems. In his interview, Nicolas details how technical debt has impacted his work throughout the years, especially for systems that require maintenance over decades. He also explains how technical debt brings challenges around maintaining several versions of the same product.

Kevin Lingerfelt

Kevin Lingerfelt is a software developer working at Buoyant. Kevin was previously a software engineer at Twitter, where he experienced all the pain related to scaling the architecture of the website and switching from a monolithic application to a multi-services approach. His experience of technical debt is detailed in a separate study on Twitter that details what challenges the company faced and how it overcame them.

Vadim Mikhnevych

Vadim Mikhnevych is an application architect at SoftServe, Ukraine. He has been working with Java since 2005, mostly in telecom and healthcare projects. Having more than 15 years of experience in software development, he has seen his fair share of technical debt.

Andriy Shapochka

Andriy Shapochka is a principal technology consultant at EPAM Systems, advising enterprises and software vendors on digital transformation and modernization of their systems. In the interview, Andriy shares his experience of the typical and most challenging technical debt items businesses face in the context of their enterprise architecture.

Things You Will Learn

This book is focused on learning by experience and illustrates each chapter with actionable insights you can use every day.

Evaluate Technical Debt

Technical Debt is a necessary evil. Learn how to measure and evaluate Technical Debt, to know when it's too much and when it's time to pay it down.

Improve your Coding Skills

We provide numerous examples and code snippets, and explain through these how you can identify and avoid the most common forms of coding debt.

Increase your Team Velocity

Detect problematic communication patterns and team structure and interaction problems that can breed Technical Debt.

Software Design and Technical Debt

Learn how you can use automated tools to measure design debt and calculate mitigation strategies and their ROI.

Understand Social Patterns

Understand the extensive social debt "smells" that can disrupt even the best-planned tech project, and how to mitigate them.

Communicate With Business Leaders

Learn concrete strategies to talk the language that will convince business professionals about the need to deal with the challenges of technical debt.

About The Authors

Representing decades of software engineering and design expertise.

Neil Ernst

Neil Ernst is Assistant Professor of Computer Science at the University of Victoria. Neil and his students work at the intersection of software requirements and software design.

Previously he was a senior researcher at Carnegie Mellon's Software Engineering Institute and holds a PhD from the University of Toronto.

  • 2,000+ citations on Software Engineering publications
  • Chair of International Conference on Technical Debt 2022
  • Associate Editor of Journal of Empirical Software Engineering

Reach Neil on Twiter or Linkedin

Julien Delange

Julien is the founder of Code Inspector, a platform that helps developers write better code, faster.

Julien was previously a tech lead at Twitter, Amazon Web Services. He also worked at Carnegie Mellon's Software Engineering Institute and at the European Space Agency. Julien has a PhD in Computer Sciences from TELECOM ParisTech.

  • Founder of Code Inspector
  • Previous tech lead at Twitter and AWS
  • Author of 50+ publications and 2 patents

Reach Julien on Twiter or Linkedin

Rick Kazman

Rick Kazman is a Professor at the University of Hawaii and a Visiting Researcher at the Software Engineering Institute of Carnegie Mellon University. Kazman has been involved in the creation of several highly influential methods and tools for architecture analysis, including the ATAM (Architecture Tradeoff Analysis Method), the CBAM (Cost-Benefit Analysis Method) and the Titan and DV8 tools.

  • Author of 2 patents
  • Author of 200+ publications, including Software Architecture in Practice
  • 25,000+ citations on Software Engineering publications

Reach Rick on Linkedin