Technical Debt and Refactoring

Technical Debt

A metaphor for programming decisions and actions that create liabilities which costs us later in time and extra work.

Where does debt come from?

Sources of Debt

  • Quick and Dirty Solutions
  • Not knowing the solution
  • Not testing your code
  • Experiments that become features

Quick and Dirty Solutions

  • "We don't have time to do it right.
  • "Let's see if people even use this first."
  • "This works, I just went with it"

Not Knowing the Solution

  • Don't always know the right solution
  • How do we model the problem?

Not testing your code

  • Manually verifying code doesn't scale
  • Tests show usage and functionality
  • Hard to make changes if it isn't tested

Experiments that become features

  • Similar to some of the other ones
  • Some times we need to validate hypothesis

Classifying Debt


Creating crippling interest payments or lots of work to fix for future you or other developers.



A conscious decision to move fast to get a release out or hit a deadline or maybe the code won't be touched again.



Releasing code that you don't even know is debt, not knowing best practices or the right solution.



Knowing that you might want to change or clean up or redesign it later but ship anyway.


Technical Debt Quadrant

Dealing with debt

Not my problem

Good Debt

Manageable debt that we can deal with. Payments are manageable and isn't ballooning.

Bad Debt

Begins to effect developer productivity. Hard to keep up or make changes. Increased time and effort for simple changes.

Maybe it is our problem

  • Eventually debt slows you down
  • Rewrite but this takes a while
  • Let's just add on to our code?


The let's pay down some debt.

Refactoring can help us

  • Simplify existing code
  • Tweak behavior to match new requirements
  • Apply new things we've learned

Refactoring in Progress

Once we start to refactor we might not always make things better immediately. We might make things worse

Basic Refactoring Techniques

Reduce Class Sizes

Isolating and modifying classes to own less code.

Reduce Class Sizes

  • Look at instance variables
  • Look at methods
  • Try to find responsibilities
  • Break out responsibilities into new classes

Extract Method

Break up large methods into smaller ones.

Extract Method

  • Find a large method

  • Write a test that covers the method

  • Move a chunk to a new method

  • Call new method from large method



Technical Debt and Refactoring

By Aaron Gunderson

Technical Debt and Refactoring

A talk for RCOS on 10/25/18 about technical debt and refactoring.

  • 194
Loading comments...

More from Aaron Gunderson