This chapter is from the book
This chapter is from the book
This chapter is from the book
Technical Debt A-B-C
Many practitioners today see technical debt as a somewhat evasive term to designate poor internal code quality. This is only partly true. In this book, we will show that technical debt may often have less to do with intrinsic code quality than with design strategy implemented over time. Technical debt may accrue at the level of overall system design or system architecture, even in systems with great code quality. It may also result from external events not under the control of the designers and implementers of the system.
This book is dedicated to defining principles and practices for managing technical debt—defining it, dissecting it, providing examples to study it from various angles, and suggesting techniques to manage it. Our definition of technical debt 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.
We like this definition because it does not fall into the trap of considering only the financial metaphor implied by the term debt. Although the metaphor carries an interesting financial analogy, technical debt in software is not quite like a variable-rate mortgage or an auto loan. It begins and accumulates in development artifacts such as design decisions and code.
Technical debt also has a contingent aspect that depends on something else that might or might not happen: How much technical debt you need to worry about depends on how you want the system to evolve. We like that this definition does not include defects in functionality (faults and failures) or external quality deficiencies (serviceability), as lumping together defects and technical debt muddies the water. System qualities, or quality attributes, are properties of a system used to indicate how well the system satisfies the needs of its stakeholders. The focus on internal quality is the lens through which these deficiencies are seen from the viewpoint of the cost of change. Technical debt makes the system less maintainable and more difficult to evolve.
Technical debt is not a new concept. It is related to what practitioners have for decades been calling software evolution and software maintenance, and it has plagued the industry ever since developers first produced valuable software that they did not plan to throw away or replace with new software but instead wanted to evolve or simply maintain over time. The difference today is the increasing awareness that technical debt, if not managed well, will bankrupt the software development industry. Practitioners today have no choice but to treat technical debt management as one of the core software engineering practices.
While technical debt can have dire consequences, it is not always as ominous as it may sound. You can look at it as part of an overall investment strategy, a strategic software design choice. If you find yourself spending all your time dealing with debt or you reach the point where you cannot repay it, you have incurred bad debt. When you borrow or leverage time and effort that you can and will repay in the future, you may have incurred good debt. If the software product is successful, this strategy can provide you with greater returns than if you had remained debt free. In addition, you might also have the option to simply walk away from your debt if the software is not successful. This dual nature of technical debt—both good and bad—makes grappling with it a bit confusing for many practitioners.
We will return to the financial metaphor later to investigate whether there are some software equivalencies to the financial ideas of principal, interest, repayment, and even bankruptcy.