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
  

Reckless

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

Prudent

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

Inadvertant

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

Deliberate

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

Technical Debt Quadrant

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?

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

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