Technical debt isn't evil
Read time: 3 minutes.
Technical debt is a concept originally introduced by Ward Cunningham, one of the authors of the Agile Manifesto. There are multiple interpretations of what technical debt is, but I am going to focus on the financial debt metaphor. Like financial debt, technical debt is something you can borrow in the present in order to achieve a goal quicker but will have to be paid back in the future. Not doing so can lead to inconvenient consequences. In software development, this typically translates into shortcuts that will get a feature delivered faster, but that will eventually need to be refactored (or even re-written). It’s the act of prioritizing speed over perfection, intending to make it better at a later, more convenient time. Using the financial analogy, the longer it takes you to pay the debt, the more interest you will end up paying. Interest has a compounding effect. In the software development world, this interest translates into how increasingly difficult it will become to keep building on top of the debt.
When I first started building software professionally, I became extremely interested in learning how to develop good software. Not the stuff that they teach you at school, but the attributes that make a project maintainable and scalable. The qualities that make your code more readable and easier to collaborate. So I started reading a lot and tried to learn as much as possible about what writing good, clean code really means. Additionally, on the financial side, I had never lived above my means, and I had been privileged enough to not be in big financial debt. Naturally, the concept of technical debt became a synonym of evil to me. I think it was a combination of inexperience, not understanding what benefits it can provide, and the misuse of the term.
We can classify technical debt as intentional or unintentional. Intentional is the one you know you are taking because there are clear business purposes and immediate gains. Unintentional, on the other hand, is the one you didn’t even know you were taking, typically because you did not have a perfect understanding of the requirements. We could argue that unintentional debt is unavoidable and somewhat necessary for shipping software, so let’s focus on intentional debt.
At this point, it is important to also distinguish between debt and bad engineering. This was not always clear in my mind, and it is easy to confuse. Debt does not necessarily equal bad practices. It could, but it doesn’t have to. In fact, I would argue that you should be quite careful when taking intentional debt. Following good practices (like unit tests) could help drastically at repayment time. When developers excuse widespread bad practices as technical debt, you should be suspicious that it might not have been deliberate debt (as we have defined it) in the first place. More likely, it’s a smell of bad engineering practices. Particularly if there is no plan to improve it, and it’s negatively impacting product development.
So what changed my mind? Building products from scratch. The process of building something new is totally different than maintaining a mature codebase. When you are building something that does not exist, you need to make sure what you are building is something people want. You don’t get extra points for having the most elegant architecture if you are solving a problem nobody has. During the pre-product-market fit stage, taking a little bit of voluntary technical debt can be smart and advantageous. It will allow you to validate a hypothesis much quicker. You might be able to optimize time to market. Perhaps you could even close a deal today instead of next month. Sure, you need to have a plan to refactor and make the code better later, but the reality is that there is a big chance you might have to throw away the whole thing anyway.
Like VC money, when done responsibly, technical debt can be an extremely useful tool for startups. The challenge, like in the financial world, is managing it. Just make sure you understand the drawbacks, don’t compromise good practices too much, and you are willing to pay back what you owe.
Subscribe via RSS