Prioritizing Your Technical Debt


Steve Garnett from Ripple Rock (an IT consulting company that assists customers in improving their software development capabilities) is one of many who has experienced Technical Debt on a project he worked on in the past. His new blog post captures a common problem: you know the Technical Debt is there, you know that it’s going to be difficult to fix… so how do you convince management that you need the time and resources to deal with it?

To answer this question you first need to understand if your Technical Debt is worrisome for your company or not. The quick answer is: Technical Debt is a problem when it starts to impede on your velocity.

When this starts to happen, not only will it take you longer and longer to get into production, but your product will become less stable, your stakeholders and even you team will start to lose trust, and this will automatically impact the consumers.

To this point however, I believe that not all Technical Debt is bad, and depending on your company’s needs it can be used as a strategic tool to gain a competitive advantage in the market. Steve recommends referring to Martin Fowler’s quadrant to help your company understand what is or isn’t acceptable for your organization in terms of Technical Debt.

The most interesting part of this blog however are the tactics shown to prioritizing the pieces of Technical Debt that have been pinpointed. Which ones do you start with first? You want to focus on the items that are having, and will have in the close future, the most impact on the business. So here some things that the blog post recommends looking at:

  • Compare the time that will be needed to fix each item of Technical Debt (i.e. the interest) with the effort associated to fix these same items of Technical Debt (i.e. the principal). If there is an item that has a very high interest with a relatively low principal, then that’s the one you want to focus on fixing first
  • Compare the amount of times that the code will be touched over the next 6 months. An item of Technical Debt might have a very high interest but might only be touched once in the next 6 months. Does it make sense to fix that item or the one that has a lower interest but will be touched 10 times in the next six months?
  • What is the business value and strategic intent associated to each of these items of Technical Debt? Which systems are critical to the future of your business? You logically want to focus your effort on fixing the items that are critical to your company and could potentially have an impact on business value

You can read the full blog post here which provides more details and slides – definitely worth the read!

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item