Technical debt can be best understood by breaking it down into the principal and interest components. The principal is the work that goes into building new features, and the interest payments are the workarounds developers need to perform to sidestep risks and inefficiencies in the code. The ‘risks and inefficient code’ piles up and create large interest payments that hamper the speed of technology modernization.
Analogous to financial debt, code debt is okay if you have a plan to clear it in time. Otherwise, compounding interest can create a vicious cycle that never ends. As financial debt can drive businesses into bankruptcy, technical debt can mean a slow death for engineering projects.
In a recent survey by McKinsey, CIOs confirmed that between 10–20 percent of the technology budget for new product development is diverted toward resolving issues related to tech debt. CIOs also estimate that technical debt amounts to 20–40 percent of their entire technology value pre-depreciation, which means hundreds of millions of dollars for larger organizations.
Anything from strategy, talent, process, and architecture can drive technical debt.
Here are a few:
Measuring tech debt isn’t as black and white as financial debt. Technical debt is the difference between the actual time a development team takes to complete a feature and the time it would have taken if the code were elegant and clean, says Martin Fowler.
However, Martin quickly points out that working with such an imaginary estimate can be challenging and proposes a more realistic process that involves including technical debt stories from developers. When developers add technical debt stories to their product backlog—which can look like, “I spent 10 hours extra on this feature because of unclean code in the XYZ module”—technical debt can be measured.
When development teams can compare the interest payments to the principal, they can make informed decisions around paying off the principal.
Pointing out the difference between bad code and technical debt is essential, too. Technical debt is not the same as a code mess. If a suboptimal design, let’s say, allows a business to meet a schedule or a particular customer need, then it’s a technical debt that should be paid off in time. However, when a coding decision is not intentional or reasoned, it’s simply a code mess.
The goal is not to eliminate tech debt entirely, as that would require devoting heavy resources to remediation tasks rather than building competitive differentiation. The goal is to make informed decisions about repaying the principal in the wake of significantly compounding interest.
Here are some starting ideas for technical debt resolution:
Hivel helps identify technical debt through an out-of-the-box dashboard that allows you to clearly see tech debt as a percentage of the total work done. It allows you to drill down to the repositories causing the highest tech debt, and take actions such as helping you find your next project that needs TLC, estimate better when you touch those projects, consider refactoring those projects, and more.
Our dashboards are designed exclusively for CTOs and engineering leaders to offer a bird’s eye view of engineering productivity to help them build better software faster.