The Dangers of Tech Debt and How to Manage Them

What is technical debt?

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.

Signs of tech debt in your engineering process

Here are a few:

• Your developers are focused on turnaround time over the quality of code.
• Product maintenance is expensive, and development involves hurdles and workarounds.
• You have quick fixes and then quick fixes to fix bugs in the quick fixes, and it goes on.
• Developers promise to go back to fix the workarounds but never get to the task.
• The development team starts missing deadlines.
• Developers appear frustrated and stressed, and the code is a mess.
• The development team deviates from the project roadmap frequently.

The cost incurred on account of tech debt

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.

‍

Quick and timely technical debt resolution practices

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:

• Start with a standard definition of tech debt. Unless your engineers know and understand technical debt, they can’t make better choices. Prime them to identify technical debt.
• Dedicate resources to tackle tech debt. Once you have a unified view of the debt, allocate funding, people, and resources to clearing it. Mobilize a long-term ongoing strategy instead of a short-term intensive.
• Gain insight into tech debt. You don’t know what you don’t know. There is little that engineering leaders can do without learning about the intensity and volume of their technical debt.
• Encourage developers to clean up the tech debt on an ongoing basis. The boys scout rule says: “Always leave the campground cleaner than you found it.” The same applies to the code. Irrespective of who wrote the original code, encourage developers to clean up the old code while touching that piece of code for a new feature. 

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.

Request a demo or try Hivel for free today.