Accumulated short-term compromises and hacks in a codebase that must be paid down over time. Side effects large amounts of tech debt include decreased velocity of making changes and frequent breakages. However, used well, tech debt can increase the velocity of a team and get more done in less time.
See also:
Links to this note
-
Taking an Airplane into the Water
The user is complaining that our boat is leaking through the windows, it’s unstable, and too slow. Sometimes you have to remember that some users will never be happy with your product because they decided to take an airplane into the water.
-
GDP Declined by $181 Billion Due to COBOL
A recent paper analyzed the causal effects of delays in updating unemployment insurance systems written in COBOL. States that used COBOL to process UI claims had a 4.4% decline in total card consumption compared to states that didn’t use COBOL. The author’s Fermi estimate is a $181B decline in real GDP due to COBOL.
-
Smart Contracts Are a Computing Model That Requires Maintenance Forever
Smart contracts that run on a distributed ledger effectively need to work forever to be useful. Working forever requires maintenance and security—the longer a computer program runs, the more exposure it has to change and the opportunity to be exploited.
-
High performing engineering teams continuously raise the bar for technical quality. Previous technical decisions are likely to not meet the current technical quality bar. Closing the gap between the two helps address tech debt and adopt a growth mindset about the team and codebase. All teams that are improving quality will notice the gap and that is to be expected. Failure to close that gap leads to more tech debt.
-
Product debt is when promises made about functionality exceed what the product can actually do. When this happens there is only two things that can be done: 1) make up for it with manual work or 2) commit to building the functionality. If you stop doing 1) the customer will be disappointed. If you keep adding product debt and never do 2), the product will never keep up and you’ve inadvertently ended up building a services business.
-
When two people have competing ideas (let’s call them idea A and idea B), it’s common to compromise somewhere between idea A and idea B (let’s call that idea C). The problem is neither person thought idea C would work to begin with otherwise they would have argued for it. Worse, both sides will harbor some resentment that idea C doesn’t work. Compromise leads to the worst outcome—a third idea that doesn’t work and resentment from both people.
-
As software grows, patterns and practices naturally evolve. Inevitably, someone comes to the conclusion that a change should happen and code should be migrated to the new thing.