On tech debt
Last updated
Was this helpful?
Last updated
Was this helpful?
Technical debt: The difference between the code and technical systems we have today vs. what we wish we had.
Major dimensions of tech debt:
Sometimes, debts are the result of early mistakes not being caught. We didn’t know that there is a better way, or we didn’t know that there is already a system for X. (Oversight)
Sometimes, debts are the result of us having learned more since the original creation of the asset in question. (Hindsight)
Sometimes, debts are the result of the context changing. A consumer who invested heavily in Betamax in the 80s may have been making a reasonable decision. By 1990, that choice was clearly wrong and incurring friction and costs as a result. Debts may accrue purely as a result of our technical systems not being fully isolated from the rest of the world. (Context)
Sometimes, debts are the result of questionable accounting or short-term priorities. We may decide we have a product requirement that demands feature Z in Q1, while adding it to our existing system will take until Q2. Introducing a new system may allow us to meet short-term deadlines, but usually ignores the full-lifecycle accounting: it’ll be harder to merge the two systems or turn one down. Total cost of ownership for inventing a new system should be considered front-and-center. (Lifecycle)
If we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’.
--
Tech debt is more like pollution than financial debt.
: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. Relevant xkcd: