Tech debt
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’. – Dijkstra
Tech debt is more like pollution than financial debt.
Hyrum’s law: 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: https://xkcd.com/1172/