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
-------------------------------------

* `A Taxonomy of Tech Debt <https://engineering.riotgames.com/news/taxonomy-tech-debt>`_

    * 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 <https://www.honeycomb.io/blog/anything-but-tech-debt>`_

    * 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 <https://computersandpeople.com/technical-debt-is-holding-us-back/>`_
* `How Google Measures and Manages Tech Debt <https://newsletter.techworld-with-milan.com/p/how-google-measures-and-manages-tech>`_

    * 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 <https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first/>`_
* `Ingineering.IT — DevOps, Technical Debt, and Adaptive Organizations <https://web.archive.org/web/20160418235955/https://blog.ingineering.it/post/21311393348/tech-debt>`_
* `On technical debt <https://medium.com/@MostlyHarmlessD/on-technical-debt-7bac65edf349>`_

    * 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")

* `Stop saying "technical debt" <https://stackoverflow.blog/2023/12/27/stop-saying-technical-debt/>`_
* `Tech debt - the plague of digital businesses that never seems to go away - part 1 | CTO Craft <https://ctocraft.com/blog/tech-debt-the-plague-of-digital-businesses-that-never-seems-to-go-away-part-1/>`_
* `Tech debt is not a burden, it's a strategic lever for success — Reforge <https://www.reforge.com/blog/managing-tech-debt>`_

    * 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? <https://unferled.substack.com/p/can-investing-technical-debt-2x-team-impact>`_

    * `Betteridge might say no <https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines>`__ but this piece actually says "maybe"
    * Calls out the problems of the term, and the value of prioritisation and evaluation

* `Technical Debt: How much is a good thing? | CTO Craft <https://ctocraft.com/blog/technical-debt-how-much-is-a-good-thing/>`_
* `Towards an understanding of technical debt <https://kellanem.com/notes/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")

* `What is Technical Debt? <https://lauratacho.com/blog/what-is-technical-debt>`_

Financial Analogies
-------------------

Lots of folks like to lean in to the "debt" part to varying degrees:

* `Bad code isn’t Technical Debt, it’s an unhedged Call Option <https://higherorderlogic.com/programming/2023/10/06/bad-code-isnt-technical-debt-its-an-unhedged-call-option.html>`_
* `Similarities Between Tech Debt and 'Money' Debt <https://marcgg.com/blog/2025/02/20/tech-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")

* `Tech debt metaphor maximalism - apenwarr <https://apenwarr.ca/log/20230605#>`_

Other Debts
-----------

Adjacent to "technical debt", there's also:

* `Conceptual Debt is Worse than Technical Debt <https://medium.com/@nicolaerusan/conceptual-debt-is-worse-than-technical-debt-5b65a910fd46>`_

    * Others would call this simply another type of technical debt, but there's value in discussing it with specificity

* `How to Address Tech Debt vs. Product Debt vs. Business Debt | by Julius Uy | Big O(n) Development | Medium <https://medium.com/big-on-development/how-to-address-tech-debt-vs-product-debt-vs-business-debt-42d43d5f768c>`_
* `Intellectual debt <http://blog.ucant.org/?p=519>`_
* `Management Debt | Stay SaaSy <https://staysaasy.com/management/2023/01/12/management-debt.html>`_
* `Start-ups and Emotional Debt <http://www.evanmiller.org/start-ups-and-emotional-debt.html>`_


See Also
--------

* `Justin Blank's Characterizing Tech Debt <https://justinblank.com/notebooks/characterizingtechdebt.html>`__