Slides: http://www.sei.cmu.edu/community/td2013/program/upload/TechnicalDebt-ICSE.pdf
Business vs Technical viewpoints
- Business staff tends to be optimistic about debt
- Technical staff tends to be pessimistic about debt (religious and aesthetic)
- These attitudes are often not conscious
- Debt is a tool, neither inherently good nor bad
Short- vs Long-term debt
- Short: violating coding standards, "we'll write these unit tests after we ship"
- Long: "we won't need to support this platform for the foreseeable future, so don't target it"
Intentional vs Unintentional
- Intentional: conscious decisions
- "we need to ship ASAP, so skip tests for now"
- Unintentional: junior developer, shitty contractor, acquisition, refactor gone south
"Interest payments" on technical debt: the bad things that debt imposes
- time wasted by consequences of incomplete tests, support costs, bug frequency
Analogies to expected vs present value, opportunity cost Debt Service Coverage Ratio (DSCR): "ratio of work spent on advancing the software vs. keeping the software from sliding backwards" Credit rating: team with lots of unintentional debt has less ability to take on more
Consider debt's interest rate
- not all debt is equal
- pay off high interest debt before low
- some low interest debt may be low enough that you never have to pay it off
Unlike financial debt, when a system is retired, all its technical debt is retired with it
- benefit of paying off debt is directly related to length of time remaining in system's lifespan
Before deciding to take on debt (McConnell slide 41-42):
- Do we have believable estimates for the debt and non-debt options?
- Cost/benefit analysis of quick & dirty vs "clean" options, with attempted mindfulness of of immediate and eventual costs.
- The "interest payment": estimate its extent of damage and payment structure
- Can we track this specific debt?
- Have we considered all options? Perhaps there's a lower-interest option we could implement at low immediate cost.
- Who will own the debt?
How much debt is enough/too much?
- No correct answer. Technical staff is often too extreme: "zero debt"
- Best indicator: decreased velocity
- Implication that work/usage is required to recognize existence of debt:
- Thus, debt is acceptable in cases where code doesn't need to be maintained
Indicators of undesirable debt:
- High interest rate
- High minimum payment
- Required, ongoing payments
- Debt is untrackable
- Debt is not intentional
- Low ROI
Tracking debt
- Log of debt items
- Monitor project velocity, amount of rework vs maintenance budget
Examples of good vs bad reasons to pay down technical debt: slides 49-54
"Justification for reducing debt needs to be explained as a business benefit", not because something is "old", "crufty", "not object-oriented", etc.
Approaches to actually pay down debt:
- Debt reduction period immediately following product release
- Amortize small debt payments into each iteration (e.g. 10% of effort of each)
- Above a certain threshold, debt reduction must be approved as a separate project.
- Individuals rotate through debt-reduction duty
- Offshore resources are used to reduce debt (wtf..?)
Summary: What can we do with technical debt?
- "Main value of technical debt is reifying a concept that's otherwise too intangible to be handled well"
- We can:
- Talk with technical staff about it
- Communicate to business staff the implications of it
- Measure the amount of it
- Make explicit decisions about whether we should take on more of it
- Get input from the business about whether the business believes we should have less or more of it
- Strategize how to avoid it
- Track it
- Make explicit decisions about when and how to reduce it