What do you think?
Rate this book
Managing Technical Debt: Reducing Friction in Software Development
“This is an incredibly wise and useful book. The authors have considerable real-world experience in delivering quality systems that matter, and their expertise shines through in these pages. Here you will learn what technical debt is, what is it not, how to manage it, and how to pay it down in responsible ways. This is a book I wish I had when I was just beginning my career. The authors present a myriad of case studies, born from years of experience, and offer a multitude of actionable insights for how to apply it to your project.”
–Grady Booch, IBM Fellow
Master Best Practices for Managing Technical Debt to Promote Software Quality and Productivity
As software systems mature, earlier design or code decisions made in the context of budget or schedule constraints increasingly impede evolution and innovation. This phenomenon is called technical debt, and practical solutions exist. In Managing Technical Debt , three leading experts introduce integrated, empirically developed principles and practices that any software professional can use to gain control of technical debt in any software system.
Using real-life examples, the authors explain the forms of technical debt that afflict software-intensive systems, their root causes, and their impacts. They introduce proven approaches for identifying and assessing specific sources of technical debt, limiting new debt, and “paying off” debt over time. They describe how to establish managing technical debt as a core software engineering practice in your organization.
Managing Technical Debt will be a valuable resource for every software professional who wants to accelerate innovation in existing systems, or build new systems that will be easier to maintain and evolve.
–Grady Booch, IBM Fellow
Master Best Practices for Managing Technical Debt to Promote Software Quality and Productivity
As software systems mature, earlier design or code decisions made in the context of budget or schedule constraints increasingly impede evolution and innovation. This phenomenon is called technical debt, and practical solutions exist. In Managing Technical Debt , three leading experts introduce integrated, empirically developed principles and practices that any software professional can use to gain control of technical debt in any software system.
Using real-life examples, the authors explain the forms of technical debt that afflict software-intensive systems, their root causes, and their impacts. They introduce proven approaches for identifying and assessing specific sources of technical debt, limiting new debt, and “paying off” debt over time. They describe how to establish managing technical debt as a core software engineering practice in your organization.
Managing Technical Debt will be a valuable resource for every software professional who wants to accelerate innovation in existing systems, or build new systems that will be easier to maintain and evolve.
272 pages, Paperback
Published June 6, 2019
31 people are currently reading
170 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 5 of 5 reviews
February 28, 2020
In software development, technical debt is understood as something in software design that slowly reduces the speed of development. To mix metaphors, technical debt causes friction in the development process. Over time, work arounds cause “interest” to accrue on the principal of bad design. The business and software development are negatively impacted, and eventually a “tipping point” is reached. Then a plan is made to pay down some (but usually not all) of the technical debt, and much like a mortgage, the code and the business around it become more manageable.
These three authors explore these themes in depth in this work in the field of software engineering. It’s not necessarily a fun topic, but it’s one that any experienced software developer can relate to. The central metaphor of debt repayment also provides a concept that is relatable to the business-people around software. Jumping from new feature to new feature without addressing issues of architecture has a cost, and this book explicates a language and a framework to deal with it more effectively.
The book explores nine principles about technical debt. Each one of these seems basic, yet they explain a more profound point.
1. Technical debt reifies an abstract concept.
2. If you do not incur any form of interest, then you probably do not have actual technical debt.
3. All systems have technical debt.
4. Technical debt must trace to the system.
5. Technical debt is not synonymous with bad quality.
6. Architecture technical debt has the highest cost of ownership.
7. All code matters!
8. Technical debt has no absolute measure—neither for principal nor interest.
9. Technical debt depends on the future evolution of the system.
This topic is not sexy (and I don’t know of any topic termed “debt” that would be considered “sexy”). Nonetheless, this book provides specific ways to tackle the debt and to raise awareness of these concepts in software teams. Reading an in-depth analysis on this topic is necessary for all software developers who aim to achieve mastery of their craft. This book will certainly help them take such a step.
These three authors explore these themes in depth in this work in the field of software engineering. It’s not necessarily a fun topic, but it’s one that any experienced software developer can relate to. The central metaphor of debt repayment also provides a concept that is relatable to the business-people around software. Jumping from new feature to new feature without addressing issues of architecture has a cost, and this book explicates a language and a framework to deal with it more effectively.
The book explores nine principles about technical debt. Each one of these seems basic, yet they explain a more profound point.
1. Technical debt reifies an abstract concept.
2. If you do not incur any form of interest, then you probably do not have actual technical debt.
3. All systems have technical debt.
4. Technical debt must trace to the system.
5. Technical debt is not synonymous with bad quality.
6. Architecture technical debt has the highest cost of ownership.
7. All code matters!
8. Technical debt has no absolute measure—neither for principal nor interest.
9. Technical debt depends on the future evolution of the system.
This topic is not sexy (and I don’t know of any topic termed “debt” that would be considered “sexy”). Nonetheless, this book provides specific ways to tackle the debt and to raise awareness of these concepts in software teams. Reading an in-depth analysis on this topic is necessary for all software developers who aim to achieve mastery of their craft. This book will certainly help them take such a step.
November 1, 2022
This book does three things very well:
- It explains what technical debt is and how it is different from defects/bugs. Their definition is as follows: "In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities—primarily, but not only, maintainability and evolvability."
- It emphasizes that not all technical debt is bad; a distinction should be made between unintentional and intentional technical debt. The latter recognizes there can be a benefit to taking on technical debt in the short term, e.g., to be faster to market.
- It argues you should monitor technical debt in the same system you use to monitor other work items, e.g., your backlog.
But while a clear definition of technical debt, recognizing its pros and cons, and a recommendation to track it is useful, it shouldn't take 237 pages of dry abstract academic writing with endless repetition and forward/backward references to explain this.
I was also left wondering who the intended audience is. I presumed software architects in industry, but at one point the recommendation is to talk to the software architect on the team to help identify technical debt. The authors' perspective as researchers observing software development teams shines through; this is not a relevant perspective to practitioners. The "practical" advice given stays in the overly abstract realm of "context-specific considerations", "business governance practices", "quality attributes", and "business goals".
In short, this is a badly written book without a clear structure or focus for the reader. The topic covered is relevant to practitioners, but probably better communicated in a different format.
- It explains what technical debt is and how it is different from defects/bugs. Their definition is as follows: "In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities—primarily, but not only, maintainability and evolvability."
- It emphasizes that not all technical debt is bad; a distinction should be made between unintentional and intentional technical debt. The latter recognizes there can be a benefit to taking on technical debt in the short term, e.g., to be faster to market.
- It argues you should monitor technical debt in the same system you use to monitor other work items, e.g., your backlog.
But while a clear definition of technical debt, recognizing its pros and cons, and a recommendation to track it is useful, it shouldn't take 237 pages of dry abstract academic writing with endless repetition and forward/backward references to explain this.
I was also left wondering who the intended audience is. I presumed software architects in industry, but at one point the recommendation is to talk to the software architect on the team to help identify technical debt. The authors' perspective as researchers observing software development teams shines through; this is not a relevant perspective to practitioners. The "practical" advice given stays in the overly abstract realm of "context-specific considerations", "business governance practices", "quality attributes", and "business goals".
In short, this is a badly written book without a clear structure or focus for the reader. The topic covered is relevant to practitioners, but probably better communicated in a different format.
February 16, 2023
Legacy systems are one of the largest threats facing organizations today. Not only that they put them at danger of hacking, that they make them slow, that they make IT and personnel costs shoot through the roof, but they simply often prevent incumbents from applying new technology to be at least on par with their competitors.
Dealing with legacy is not only a task to be left to IT department but must involve the entire enterprise, in particular the C-level. To overcome legacy problems read this very well-structured volume that helps you build a game plan for tackling technological debt. Which systems to upgrade, which to replace, and which to leave as they are? And how to start extricating yourself from the old systems you inherited? Those are some of the big questions answered in Managing Technical Debt.
Dealing with legacy is not only a task to be left to IT department but must involve the entire enterprise, in particular the C-level. To overcome legacy problems read this very well-structured volume that helps you build a game plan for tackling technological debt. Which systems to upgrade, which to replace, and which to leave as they are? And how to start extricating yourself from the old systems you inherited? Those are some of the big questions answered in Managing Technical Debt.
May 10, 2020
Apresenta uma forma sistemática para gerenciar dívidas técnicas que inclui: catalogar dívidas técnicos, similar a descrições de histórias de usuário; alinhar a estratégia de evolução do produto à estratégia de resolução da dívida; e processos para identificar causas da dívida técnica.
January 31, 2022
Software Engineering book. Does a good job of explaining technical debt, but its expansion on details is dry and mechanistic (even for a software engineering book).
Displaying 1 - 5 of 5 reviews