Any software project whether it is a new application or a mature product, you must have heard the commonly used term technical debt – that is basically a metaphor to indicate long term impacts from short term benefits. Technical debt is there because it brings several benefits, these benefits come in the form of increased development speed, shortened time to market, or early validation of user response on a new product feature. Like any other debt, technical debt can be good or bad for a software project. Whether it is good or bad depends on how debt is utilized. Any good debt uses the loaned  resources to create value that is more than the cost you will be paying to own the debt. Let’s take a basic example – if you take a $1000 loan with 5% annual interest rate and use this loan to create something that is worth $1200. Then after repaying the debt and interest you created a net value of $150 by the end of the year. Technical debt is not different. It could be beneficial to have technical debt if having technical debt produces greater value compared to the cost of debt and you have a clear plan to pay-off the debt and ongoing interest cost associated with it. Point to note here is that you are paying off the debt and interest and capitalizing the value you created. But if debt is not paid off then the principle of compounding will kick in and debt will continue to grow and the cost of debt will grow with it.

Next question is how you can define a technical debt, how you measure it and how you can make sure that it is being paid off over time. Origin of technical debt in a project starts when we start developing the project based on partial requirements rather than spending time upfront to understand full details. This brings some benefits to deliver working code to users, so users can provide early feedback to meet their needs. But these benefits come at the cost of code maintainability, performance, observability, and higher operability cost. Continuous refactoring and updating software to address these issues is the repayment of debt with interest. If this is not included in the development strategy the cost of maintaining the project – commonly known as KTLO or cost of keeping the lights on in software services – and all the initial benefits of the debt will go away with a crippling down project. That is equivalent to a bankruptcy in traditional debt terms.As a leader of a software project, your strategy should include a balance of new value creation and repayment of past debt. There are multiple ways to follow the strategy in action. Always start with prevention, the more you can avoid owning the debt the better you can manage it. Larger technical debt for small benefits is a recipe for disaster. Next is monitoring the debt, if you are not measuring how your technical debt is piling up you don’t know the urgency of repaying it and don’t know what to pay off. Things to monitor include growing backlog, software maintainability reports from the tools, your cost of operating the service etc. Having a good monitoring system in place to get the visibility of debt not only to leaders but also provide insights to the team to prioritize repayment effort. Monitoring will make sense only when repayment plans are included in the execution strategy. Good agile practices like cost of continuous refactoring, spending time to improve observability and operational efficiency with robust tooling should be included in a team’s agile culture instead of separate one-off jobs. 

Overall as a leader if you keep a pulse on monitoring the growth of debt and balance the repayment cost with value creation, technical debt can be a great source to accelerate your success. At the same time if the importance of monitoring the growing cost of debt and plan of repayment is ignored, the cost of adding new features and maintenance will exceed your budget and the project will crippled with bankruptcy.