Why is technical debt such a key metric in developer productivity? The reason is very simple–technical debt is like the invisible part of the iceberg; something that cannot be seen or measured at first glance, but has long-term, negative impacts on your code as a vessel, as well as both of the other two metrics that we’ve been looking into lately: predictability in software releases and software quality. If you are not paying attention to good design, builds, performance tests and polish you will lose the understanding of the system and expose yourself to hard-to-fix bugs and other nightmares.
In a perfect world, development teams should be able to take precautions against accumulating technical debt, but in reality simply reducing existing technical debt is a tough sell to management and is really hard to quantify. Here we refer to things like improving architecture and design through refactoring, introducing automated tests, making builds run faster and looking into new tools and technologies to make this all happen.
So when we asked software professionals “Do you work on solving technical debt?”, we were excited to see what teams had to say. Take a look:
Results: 6 out of 10 teams consider technical debt a non-priority
Those teams that replied ‘Often’ or ‘All the time’ to this question are just barely breaching the 40% level. However, ‘Sometimes’ is the largest single group at 47%–although like quality assurance, solving technical debt isn’t a one-time thing, it’s a constant exercise that needs to be incorporated in every release. Like people who only exercise or work out “sometimes”, the greatest benefits are witnessed by those who do it very frequently. In this group, 12% of teams either rarely or never work on reducing technical debt. So, we can see that 6 out of 10 teams consider technical debt a non-priority. That is, until the sky starts falling ;-)
Although this doesn’t give us the current measure of the technical debt, it gives us a much more important metric–how much attention does it get? However, actions taken to reduce technical debt are sometimes only recognized as necessary after something has gone wrong (aka “We should have done that” syndrome). So the challenges abound.
In addition to learning more about how technical debt impacts predictability and quality in software, we also expect to learn the following:
- What is the industry average for technical debt work?
- How does it change between different company sizes and industries?
- How does it correlate with various engineering tools and practices?
In short, we are hoping to give you an arsenal of real numbers to prove to your management that solving technical debt is an important part of the development process and needs to be included in every single release.