I was first introduced to the idea of splitting technical debt into two distinct parts during a conference talk given by Rebecca Wirfs-Brock. She talked about there being a real difference between simple cleanup such as renaming or adding clarity and architectural restructuring.
I’ve adopted this into my own practice and find it a very helpful distinction when determining how to approach the work.
Both technical and architectural debt come from the same root. They’re both things that are working (ie not bugs) but that are done in a way that slows us down. The way that we plan to approach each is quite different though.
Technical Debt include poor naming, badly structured code, duplication etc. They are things that tend to be localized and can be fixed in isolation. Any developer should fix this as they find it. Nobody should ever ask permission to fix technical debt.
Architectural Debt tends to be more complex and have a larger scope. Perhaps we have multiple ways to do the same thing in the codebase. Perhaps we used inappropriate or inefficient algorithms that work but not well. These things tend to be more complex to fix and we need to allocate time for them in the schedule. These are not things that we should just decide to fix in the moment - they need to be planned. We should be talking to our product owners and the team about these kinds of changes, before we make them.
Architectural debt should be tracked as all other work, on your board. It’s significant enough to justify it’s own ticket. Technical debt should just be fixed as you go. Always leave the code better than you found it.