When people talk about technical debt, they typically think about technical debt in the code. Things like unreadable code, outdated libraries and lack of automated test. Yet technical debt is broader than that. Already in 2014, the 6th International Workshop on Managing Technical Debt identified 13 categories of technical debt. Unfortunately, they are still not well-known among IT professionals, even though we could all benefit from a broader look at technical debt.
The International Workshop on Managing Technical Debt
From what I can find online, the International Workshop on Managing Technical Debt is now call the TechDebt conference and is a series of yearly conferences sponsored by the ACM/IEEE. It intends to bring together researchers and professionals to discuss technical debt.
Categorizing Technical Debt
I previously wrote about categories of technical debt along two axes: intentional vs unintentional and known vs unknown. I identified a fifth category: technical debt that emerges over time. These are categories based on how the technical debt comes about.
In their paper Towards an Ontology of Terms on Technical Debt, the researchers of the International Workshop on Managing Technical Debt categorized technical debt according to where the debt is located. This gives us a broader look at technical debt.
The categories they identified were:
- Architecture debt
- Build debt
- Code debt
- Defect debt
- Design debt
- Documentation debt
- Infrastructure debt
- People debt
- Process debt
- Requirement debt
- Service debt
- Test Automation debt
- Test debt
As you can see, the places where we can encounter debt are more numerous than one might expect. In upcoming posts, I’ll take a look at each category individually. But the key takeaway here is that technical debt doesn’t just occur in code.
You may already have thought about technical debt in some of these categories. Running on an outdated server infrastructure, for example, is a well-known example of infrastructure debt.
But other categories may not be so obvious. People or requirement debt? Not something I hear a lot of IT professionals talk about.
So we have to keep an open mind towards technical debt and be aware that we’ll encounter it in all area’s and stages of our software development lifecycle.