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’m not sure if how I use it is exactly what she had in mind, but I find it a very helpful distinction anyway. We treat the two types of debt differently and it’s worth giving them different names.
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.
Technical Debt includes poor naming, badly structured code, duplication etc. They are things that tend to be localized and can be fixed in isolation.
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.
We treat these differently, or at least we should.
Technical Debt should be fixed as we find it. This is part of the scouting rule of “always leave the campsite cleaner than you found it”. When I touch some part of the code, I should clean up that part of the code and leave it a little bit cleaner than when I arrived. No developer should ever ask permission to fix technical debt; fixing it is just part of the ongoing work.
Architectural debt is different, however. This is large and may have side-effects. It will take time and attention away from other work and needs to be effectively prioritized. We should be discussing architectural debt with our product owners and allowing them to prioritize it along with any new work that is coming in. This work should have it’s own ticket and should be on the board just as any new feature would be.
I find making this distinction helpful as it allows us to have more effective discussions around when we should just be fixing the code in the moment and when we should be putting it on the backlog to be prioritized and scheduled.
See also: Technical debt and productivity