Skip to content

Instantly share code, notes, and snippets.

@evnm
Last active December 18, 2015 00:18
Show Gist options
  • Save evnm/5695408 to your computer and use it in GitHub Desktop.
Save evnm/5695408 to your computer and use it in GitHub Desktop.
Notes on Steve McConnell's "Managing Technical Debt" keynote presentation at the 2013 International Workshop on Managing Technical Debt

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment