Why Technical Debt is not Bad Debt
Release early, release often — just don’t forget to refactor ;)
Deliver Now
As software engineers, our main objective is to deliver. Once our code works as expected, we commit it and then run it in the CI/CD pipeline.
While seemingly straightforward, it’s not as simple as it may seem. There exists a constant tension in the programming world that stems from shipping fast or slow at the cost of software maintainability aka technical debt.
Technical debt is opting for the easy solution now instead of using a better approach that would take longer. More often than not, many agile teams choose the former than the later.
Deliver now and fix it later is a very popular approach because teams are able to reduce the time it takes to get product-to-market. It’s also great because software engineers don’t have to spend too much time developing something that might be used. For many companies, it’s a fair trade off. Nevertheless, in order to make this approach work, continuous refactoring must be done — else technical debt will accumulate.
