This is part 1 in our overview series on tech debt.
Technical debt isn't a tangible entity in software development. But it's a great analogy to let us think about how the decisions we make today in how we structure our code impact our future ability to effectively develop. Any time you've been slowed down because you were dealing with old code and can't make heads or tails of how it's structured, when you realise certain things just can't be extended how they were written, or when you've been slowed down by overly complex code are all examples of the costs of tech debt. But why do we use debt as an analogy? And show we be looking to constantly go back to our old code to try to eliminate technical debt from our codebases?
As best I can tell, tech debt first cropped up as a term in 1992 when Ward Cunningham laid out the basics of the idea. He had 3 main points about what tech debt is and how it parallels financial debt:
- "Shipping first time code is like going into debt."
- "A little debt speeds up development as long as it's paid back promptly."
- "Every minute spent on not-quite-right-code counts as interest on the debt."
Let's take a look at the analogy in more depth by looking at a (semi) practical example. Let's imagine we're looking to start a lemonade stand, but only have $5 to start out. We need to buy lemons and sugar so we can start making lemonade and start making money, but $5 won't buy us that many ingredients.
The Git Bank offers loans to any aspiring lemonade stand owners. Their standard terms are a $50 loan with 5% weekly interest (pricey, but lemonade stands are risky investments!). We could take the loan (and go into debt) so we can buy more supplies, start selling more lemonade, and get the business off the ground faster, but is it the right decision?
- Let's say we make $1.10 for every $1 we invest into supplies and that we choose to reinvest all of our profits back into more supplies.
- At the end of the first week we would have had $9.74 if we don't take the loan vs $44.94 if we do take the loan and repay it.
- $97.44 in last day earnings
- ($50) for the loan principal
- ($5) for the interest
We can view tech debt that comes into play when we're developing new software in the exact same way. We could spend the extra time to fully refactor and fine tune every aspect of the code, but that will make it take longer to release the code and get the benefits from it. Instead we could ship it earlier, even if it's not perfect. At some point, we'll have to go back and refactor that code - the time this will take is the principal of our technical debt. We're also going to be slowed down in future development by some of the shortcuts we took - this time lost on future development is the interest we keep getting charged on our technical debt.
It seems pretty clear that taking on some technical debt can be worth it in the short term since it allows us to move faster, but how quickly should we be aiming to pay it back (ie refactor and clean up our code)? Cunningham suggested that we should pay it back immediately - and if that's easy and quick and we're going to work on that code frequently then that's a great idea. But, if we're dealing with sections of our code base that we don't actually touch all that often then it can be more efficient to actually leave some of that debt unpaid. Just like financial debt, it's not necessarily optimal to target zero tech debt.
To quickly recap:
- Technical debt is a nice analogy we can use to think about the cost/beneift tradeoffs we make with our decisions when we are developing.
- Technical debt can be split into a principal component (the cost in time it will take to refactor or fix the underlying code) and an interest component (the ongoing slowdown to future work).
- While we want to keep the ongoing costs of tech debt low, it's not necessarily optimal to target having no technical debt.
Looking to reduce your tech debt or prevent it from building up in the first place? Learn how Sourcery can help your team improve all your Python code.
Top comments (0)