Technical Debt
I have a lot of feelings about this term. In short, I think it’s an incredibly loaded term with a huge range of interpretations and understandings, which can make it dangerous to use. But it’s a valuable concept, and comes up a lot.
Metrics and categories and approaches
-
Identifies three metrics - “impact”, “fix cost”, and “contagion” - for better evaluation
Identifies four non-exhaustive categories - “local debt” (a well-contained hack), “MacGyver debt” (two distinct systems bodged together), “foundational debt” (historical decisions you’re tied to that don’t really make sense today), and “data debt” (I struggle to summarise this well, but essentially the kind of issues that come from historical decisions around data and algorithms and meaning)
Anything But Tech Debt | Honeycomb
Calls out that “tech debt” could mean any one of a large number of things, and amount to more than two thirds of the types of work an engineer might touch
Points out that if you’re struggling to negotiate time for “technical debt”, improving how you communicate and talk about it could help
As a metaphor and practice, technical debt is holding us back
How Google Measures and Manages Tech Debt
Categories (“Migration needed or in progress”, “Poor or missing documentation”, “Inadequate testing”, “Bad code quality”, “Dead code”, “Code degradation”, “Knowledge gaps”, “Problematic dependencies”, “Failed migrations”, “Outdated release process”)
Found that “No metric predicted engineer-reported technical debt”
Tech Debt Maturity Model (“Reactive”, “Proactive”, “Strategic”, “Structural”)
Balance, practical takeaways, and culture
If you want to address tech debt, quantify it first - Stack Overflow
Ingineering.IT — DevOps, Technical Debt, and Adaptive Organizations
-
Covers a number of impacts (“Time is wasted”, “Estimates are less reliable”, “It gets worse”, “It’s boring and frustrating”)
Provides assorted approaches for addressing it (“Just accept it and move on”, “Be strict”, “Borrow responsibly”)
Tech debt - the plague of digital businesses that never seems to go away - part 1 | CTO Craft
Tech debt is not a burden, it’s a strategic lever for success — Reforge
In a similar vein to “not all debt is bad debt”, dives into nuance
Identifies six types of “technical debt” (“Maintenance”, “Developer Efficiency”, “Stability”, “Security”, “Technical Product”, “Decision”)
Provides suggestions for sizing and prioritising and leveraging
Technical debt: Can investing in it unlock 2x team impact?
Betteridge might say no but this piece actually says “maybe”
Calls out the problems of the term, and the value of prioritisation and evaluation
Towards an understanding of technical debt
Identifies five (non-exhaustive) categories (“Maintenance work”, “Features of the codebase that resist change”, “Operability choices that resist change”, “Code choices that suck the will to live”, “Dependencies that resist upgrading”)
Financial Analogies
Lots of folks like to lean in to the “debt” part to varying degrees:
Similarities Between Tech Debt and ‘Money’ Debt
(“Allows you to move faster”, “You have to pay it back”, “It costs more to reimburse”, “Left unchecked, it can be disastrous”, “There are cases where you shouldn’t do it”, “Limits your ability to seize new opportunities”)
Other Debts
Adjacent to “technical debt”, there’s also:
Conceptual Debt is Worse than Technical Debt
Others would call this simply another type of technical debt, but there’s value in discussing it with specificity