not all technical debt is created equal. i've started thinking about it in three categories, and it's changed how i prioritize what to fix.
deliberate debt. you know the right solution but ship the fast one because speed matters more right now. this is the mortgage model. you're borrowing against future effort with your eyes open. this is often good. startups that refuse to take deliberate debt die of perfection.
accidental debt. you didn't know the right solution at the time, and now you do. the codebase reflects your past ignorance. this is normal and inevitable. nobody writes perfect code on the first pass because nobody fully understands the problem on the first pass.
environmental debt. the code was correct when written, but the world changed. a library you depend on is deprecated. a pattern you used is now an anti-pattern. the scale you designed for was exceeded. nobody did anything wrong. the ground shifted.
why the distinction matters
each type demands a different response.
deliberate debt should be tracked and paid down on a schedule. it's the most manageable kind because you already know the fix. you just haven't done it yet.
accidental debt requires learning. the fix isn't obvious because you first need to understand what you got wrong and what the right approach looks like. this takes research and experimentation, not just refactoring time.
environmental debt is the hardest because it can't be prevented through better engineering. the only defense is building systems that are cheap to change. small modules, clear interfaces, low coupling. you can't predict what will change, but you can make change less expensive.
status: living note. last revisited october 2025. i keep finding new subtypes but three feels like the right granularity for decision-making.