Managing Technical Debt

All Code Has Debt

The question is: are you managing it?

What Is Technical Debt?

Code that works but:

• Is hard to understand
• Is hard to change
• Has known limitations
• Uses outdated patterns

Types of Debt

Deliberate: "We'll fix this later" (document it!) Accidental: Didn't know better at the time Bit rot: Dependencies/requirements changed

Track It

// TODO(debt): This query is N+1, needs optimization
// when user count > 1000
// Created: 2024-01-15, Owner: @matt

Or use issues:

[Tech Debt] Refactor user authentication
- Currently mixed session/JWT
- Should standardize on JWT
- Estimate: 2 days

Pay It Down

Boy Scout Rule: Leave code better than you found it

// While fixing a bug in this file,
// also rename this confusingly-named variable

Dedicated time: 20% of sprint for debt reduction

With features: Refactor before adding to messy code

Don't Rewrite From Scratch

Almost always a mistake:

• You'll reintroduce old bugs
• You'll miss edge cases
• Business can't wait

Instead:

1. Strangle the old system
2. Replace piece by piece
3. Keep it working throughout

When Debt Is Okay

• Prototypes (throw away after)
• Time-critical fixes (fix properly later)
• Learning/exploring

Just make it intentional and documented.

Red Flags

• "Nobody understands this code"
• "We can't change X without breaking Y"
• "It works, don't touch it"
• Fear of deploying