Chris Dzombak

sharing preview •

Tech Debt and Refactoring

Tech Debt and Refactoring

Refactor as necessary to avoid adding tech debt during day-to-day. Add tests and rearchitect during the normal development cycle when adding to a preexisting codebase.

Taking the time to do things right makes everything take a little longer than it strictly needs to, but it allows you to avoid unpredictable delays due to tech debt avalanches. (Think of it like using reference-counting to avoid stop-the-world GC pauses.)

For writing new code, refactor frequently as requirements develop and as you learn more about the problem you’re solving and how it fits into the application’s architecture. Use tests to ensure you don’t break things as you refactor. Complete the new feature with zero addition of tech debt, even if it takes longer, since adding tech debt makes progress unpredictable.

If tech debt must be added (because deadlines are sometimes real), file an issue to track it and revisit it while the code is still fresh in the team’s minds.