What metrics do you use to measure technical debt and show how your team is managing it?
Sort By:
Oldest
Director of IT in Software2 months ago
We use several metrics to measure technical debt, including code complexity (cyclomatic complexity), code duplication, and maintainability index. Additionally, we track the number of known issues or bugs, code review feedback, and the frequency of code refactoring. These metrics help us prioritize technical debt alongside feature development, ensuring that our team addresses critical issues without compromising overall system quality.CEO in Services (non-Government)2 months ago
Do you translate any of these metrics to a business metric (e.g. revenue loss risk, cost reduction opportunity, etc.). Thanks.
Chief Technology Officer in Software2 months ago
We measure technical debt in 4 layered process: Identify , Measure , Fix and Feedback.Identify - Via Cyclomatic dependency in code base , Code smells via SonarQube and 2 step code reviews
We use Static code analysis tools and so regression on every code that moves to prod.
Measure - Code coverage on test bed and technical cost to develop ratio. Very critical to check cost of rewriting a code base and business impact it can bring.
Fix - Any code base which is out of sync is fixed. We usually move to open source high throughput tech stack if we are touching any legacy codebase.
Feedback - Continous testing on staging , checking metrics and performance and then moving the code base to prod.
CIO in Healthcare and Biotech2 months ago
We experienced this when I joined my current company. They had underinvested in IT for years and had significant technical debt. First, I had to prove it. I used Gartner data to help executives understand what the normal investment level and resource levels were for a company like ours. I didn’t just talk to them about our 2.3% investment of revenue as compared to the industry average of 4.9% at that time. I developed a slider bar chart that indicated what pushes a company to invest more than the average or less then the average. I did this because people don’t trust industry averages, always thinking they are different, special. So on the left and right of the average I listed things that make you not average. On the left side are things you can do that position you to spend less money than the average and on the right side, things that make you spend more than the average. Interestingly enough, everything on the right side of the scale best defined us. They quickly dropped the argument that we were special and didn’t need to meet the average. They finally understood that they were underinvesting. Up until that point, all they saw was that they were spending millions in IT and that was a lot to them. They never understood what the right investment level was or the levers that affect it. Next, I went back in time to show actual investment versus what we should have been investing. The chasm between the lines is what I explained to be the creation of technical debt. Meaning, we have years worth of debt to recover from. I then shifted to point to specific areas that we needed to focus on to reduce our debt, what investment would be required to do so, and the results they should expect. As a private company, shareholders see extra spending as less money going into their pocket at the end of the year so it is very important to have an “earn the right” approach. I did not ask for everything, to solve for everything. Instead, I focused on a couple of the most critical areas, asked for a modest investment, and committed to improving service levels. Once I did that, I moved on to compliance areas. After that, productivity areas. Eventually we worked our way up the trust ladder to then invest in innovation.
When you have significant technical debt, it is important to help people understand what their basic level of service expectations should be, how they should align with the level of investment. We are talking operations. Operations is #1, always. With significant tech debt, the focus cannot be projects, unless the projects are to resolve technical debt. You have to earn the right to enhance, transform, innovate and the company needs to understand that. It is very important to transition from stopping the bleeding to managing the intake funnel. The intake needs to be a very slow drip while you shift from service levels to efficiency. Efficiency gains give you capacity to shift resources from lower value work to higher value work…like compliance or productivity.
In conclusion, don’t be in a hurry. Explain technical debt to the business in business terms. Realize you need to earn the right to advance in maturity and make sure the business sees value each step of the way. Your selling point should never be “this is how other companies do it”. Your selling point should be how what you propose will deliver measurable business value to your firm.
Director of Information Security2 months ago
In 2024, we began using KRI (Key Risk Indicators) and while they are not specifically labeled as technical debit, we have two KRIs that net to reducing technical debit.1 - application rationalization: we're using Gartner's TIME analysis to assess the application portfolio and tracking the number of sunset + decommissioned software and hardware
2 - cloud vs on prem: pursuing our cloud native strategy, we're migrating on-prem servers to the cloud, which is reducing the risk of outdated apps and OS