This page is part of my personal knowledge database, that helps me to store and navigate my learnings.
Read on here for details

Technical Debt

Technical Debt is a form of Entropy, a form of system degradation. Whenever decisions are made, that prioritize short term over long term benefit a debt is added.

Examples that create Technical Debt: monkey patches intended to be temporary become permanent once shipped, necessary refactoring of foundations is omitted while new features are added on top, maintenance operations are are forgone while more complexity is added.

If this Technical Debt is not payed, that is time is invested to straighten out the fragile state, to provide a durable solution, to actually think it through - then Technical Debt keeps growing.

This ever growing Technical Debt requires increasingly more maintenance cycles to be kept in check - that is: to keep things running at status quo.

Any engineering organization has a specific amount of capacity. Technical Debt continuously consumes capacity every cycle. The amount of capacity consumed by Technical Debt can match or even outgrow the available capacity - if not addressed.

Solution to mitigate or eliminate Technical Debt - besides limiting wonky decisions - is to dedicate capacity within every cycle to address existing and new Technical Debt. Experience taught us that any organization, that does not invest at least 20% of their capacity each cycle into that (i.e. making it part of normal operations), will loose the battle and will sooner or later be left with no capacity at all.