2011/Technical Debt

From Open Source Bridge Wiki
Jump to: navigation, search

Technical debt is something that most project teams or independent developers have to deal with – we take shortcuts to push out releases, deadlines need to be met, quick fixes slowly become the standard. In this talk, we will discuss what technical debt is, when it is acceptable and when it isn’t, and strategies for effectively managing it, both on an independent and team level.

Speaker: Elizabeth Naramore

Return to this session's details

Contributed notes

Elizabeth has posted the slides from her talk on SlideShare.

(Add your notes here!)

Sumana's notes:

You have technical debt if you have untested code, suppressed errors, confusing code, inconsistencies & workarounds... code that doesn’t follow standards (code that is hard to read takes time to read)... duplicate code blocks...

  • Non-existent or improperly used VCS.
  • Unstable deployment process.
  • Individual code ownership.
  • Lack of documentation.
  • Unshared knowledge.
  • Third party code that needs updated/patched

Some technical debt is okay.

Slides distinguish between prudent and reckless, and between deliberate and inadvertent. There are thus four kinds of tech debt.

By minimizing deliberate debt, we can better handle inadvertent debt.

  • Discover where your tech debt is
  • Estimate how much there is, with something like sonar
  • Estimate how much it's costing you -- Amount of the “loan” = cost to fix “Interest Rate” = Adverse impact on

development (and the interest rate can be hard to figure out!)

  • Decide what to do with it. Either pay the principal or keep paying interest. Then task and track.

A key: make it visible. Surface the technical debt issue, make it salient, communicate as you pay it off, prevent relapse.

Sometimes chipping away at little tech debts won't get you the momentum & buy-in you need.

Dedicate time to doing this! Perhaps time right after a release. Consider having a Dedicated Debt Payer. And communicate what you're doing, and learn good habits in the future, as you would teach your children to stay out of debt.

To manage organizational change, Naramore recommends Switch: How to change things when change is hard. In the elephant-rider metaphor, direct the rider, motivate the elephant, and shape the path.