“Technical Debt” refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar- driven software schedules. Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. The ability to take on debt safely, track their debt, manage their debt, and pay down their debt varies among different organizations. Explicit decision making before taking on debt and more explicit tracking of debt are advised. (View Highlight)
The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. (View Highlight)
The second kind of technical debt is the kind that is incurred intentionally. This com- monly occurs when an organization makes a conscious decision to optimize for the pre- sent rather than for the future. (View Highlight)
Short-term debt is the debt that’s taken on tactically and reactively, usually as a late-stage measure to get a spe- cific release out the door. (We’ll call this Type II.A, “Short-Term Debt.”) (View Highlight)
: “We don’t think we’re going to need to support a second platform for at least five years, so this release can be built on the as- sumption that we’re supporting only one platform.” (We’ll call this Type II.B, “Long- Term Debt.”) (View Highlight)
Some debt is taken on in large chunks: “We don’t have time to implement this the right way; just hack it in and we’ll fix it after we ship.” Conceptually this is like buying a car—it’s a large debt that can be tracked and managed. (We’ll call this Type II.A.1, “Fo- cused Short-Term Debt.”) (View Highlight)
Other debt accumulates from taking hundreds or thousands of small shortcuts—generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on. This kind of debt is like credit card debt. It’s easy to incur unintentionally, it adds up faster than companies think, and it’s harder to track and manage after it has been incurred. (We’ll call this Type II.A.2, “Un- focused Short-Term Debt.”) (View Highlight)
Summary of Kinds of Debt Non Debt Feature backlog, deferred features, cut features, and so on. Not all incomplete work is debt. These aren’t debt, because they don’t require interest payments.
Debt I. Unintentional Debt. Debt incurred unintentionally due to low quality work II. Intentional Debt. Debt incurred intentionally II.A. Short-Term Debt. Short-term debt, usually incurred reactively, for tactical reasons II.A.1. Focused Short-Term Debt. Individually identifiable shortcuts (like a car loan) II.A.2. Unfocused Short-Term Debt. Numerous tiny shortcuts (like credit card debt) II.B. Long-Term Debt. Long-term debt, usually incurred proactively, for strategic reasons (View Highlight)
The main issue seems to be that, unlike fi- nancial debt, technical debt is much less visible, and so people have an easier time ig- noring it. (View Highlight)
Here are two approaches that can add transparency to technical debt tracking: (View Highlight)
Maintain a debt list within the defect tracking system. (View Highlight)
Maintain the debt list as part of a Scrum product backlog (View Highlight)
Different teams will have different technical debt credit ratings. The credit rating re- flects a team’s ability to pay off technical debt after it has been incurred. (View Highlight)
A key factor in ability to pay off technical debt is the level of debt a team takes on un- intentionally, i.e., how much of its debt is Type I? The less debt a team creates for it- self through unintentional low-quality work, the more debt a team can safely absorb for strategic reasons. (View Highlight)
Here are some suggestions for communicating about debt with non-technical stake-holders: (View Highlight)
Use an organization’s maintenance budget as a rough proxy for it’s technical debt service load. (View Highlight)
Discuss debt in terms of money rather than in terms of features. (View Highlight)
Be sure you’re taking on the right kind of debt. (View Highlight)
Treat the discussion about debt as an ongoing dialog rather than a single discus- sion. (View Highlight)
Here are several reasons to pay down technical debt: (View Highlight)
Note: - faster releases in future
enable functionality in areas currently blocked by debt
