Skip to content

Instantly share code, notes, and snippets.

Last active December 18, 2015 00:18
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • 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


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