Technical Debt Isn't Always A Bad Thing

You’ve probably heard managers and coworkers discussing technical debt and how it prevents your team from shipping new features as quickly as the product team wants them delivered. There’s usually some old legacy code that needs to be worked around or is difficult to modify for some hard to explain reason. When most people talk about technical debt, it’s usually considered to be a bad thing. But what if technical debt wasn’t so bad after all? What if technical debt, when used correctly, allows you to move quicker and deliver results quicker? 

Technical debt is not always bad. It’s just that: debt. Sure, you can get into a lot of trouble if you take on too much debt, but debt also gives you leverage. I can use debt to my advantage if I want to start a small business or purchase a house or a car. I get something valuable quickly, and I know that I have to pay down the debt over time. When used correctly, debt can be a good thing. But if I use debt incorrectly, like purchasing a house that I can’t afford, I can get into a lot of trouble. The key is to understand the advantages debt can give you, the risks involved, and know when it’s a good idea to use debt.  

Software teams can leverage technical debt to their advantage to speed up development. The trick is to know how to balance speed of iteration versus maintainability of the code in the long run, because the debt will have to be paid eventually. In some cases, a team may have no option but to leverage technical debt for speed, for the company to survive, or because there is uncertainty if something will work or not. 

Photo by Alexander Schimmeck on Unsplash

The incredible thing about technical debt is that unlike financial debt, you can delete code. I can’t delete the remaining balance on my mortgage I owe to the bank, but I can certainly delete the code I wrote that allowed my team to ship a product months ahead of schedule in order to gather valuable customer feedback. As the company learns about the needs of their customers, they can iterate on the product and replace the technical debt with something more scalable, more maintainable, and more permanent. We were able to move quickly, the company was able to validate a hypothesis about the customer needs, and we’re able to make the case for more time and resources to remove the debt and build the next iteration of the product. 

The main idea is to segregate technical debt so that it’s easier to delete later. Utilize interfaces and abstractions because it allows you to separate code that you are uncertain about from your core business logic that you are certain about. If code is uncertain and able to be segregated, technical debt is often a good idea. Over time you’ll learn from your customers whether or not that code provides value. If it does, it’ll probably get refactored anyway. And if it doesn’t, it should be easy to delete if you’ve done a good job keeping it isolated from the rest of your core logic. 

Knowing when and how often to use technical debt comes with experience, and the only way to gain experience is to leverage technical debt and learn from it. Sometimes you cut corners and it works out, and sometimes it comes back to bite you. You may write some quick and messy code in order to ship a feature quickly, even though you know that some edge cases aren’t covered and that it won’t scale well. If it works out, it’s time to plan for a v2. And if it doesn’t, it’s a good thing you didn’t spend a lot of time on it if you can easily delete the code. 

In either case you were able to move fast and validate your ideas quickly by leveraging technical debt to your advantage.