by Arlene Minkiewicz
| January 27, 2015
Here’s something I’ve been thinking about a lot lately - technical debt and its relationships to software maintenance costs. Technical debt speaks to the structural quality of software applications. Technical debt is incurred for many different reasons; sometimes it is intentional when shortcuts are taken to meet a time to market requirement; sometimes it occurs because a development team gets sloppy about applying good coding practices (or a development team has not documented coding practices); sometimes it happens when the technology in an application is not kept up to date and it literally gets lapped by technology.
Not all technical debt needs to be addressed (though unaddressed technical debt is likely to lead to the eventual derailment or un-maintainability of the application) so there is no direct corollary between a measure of technical debt and the software maintenance costs. But not only does technical debt speak to things that are poorly done in the application, it also speaks to things that clearly will affect the maintainability of the application. Static code analysis tools that measure technical debt look for things like uncommented methods or functions, use of global variables, unreferenced methods, artifacts with high internal complexity, etc. None of these things are things that the end user will care about so they are not going to find their way onto a list of user requested enhancements or bug fixes. They are however things that will make the user requested enhancements harder to implement. One of the hardest things that software maintainers have to do is wrap their head around the code they need to fix or update. Something that’s not hard to do if you are the original developer and if little time has passed since you wrote the code, but something that gets increasingly complex as time passes and/or the code passes from the development team to the maintenance team.
Basically technical debt is the things that the software development team knows (or should know) about what’s structurally wrong with the code they are delivering. It’s not a direct driver of software maintenance costs but it certainly is something that should be considered. In an ideal world, the first goal of a software maintenance project would be to address the most odious of known technical debt before any bug fixes or new features are addressed. In this case, the measure of technical debt is a significant driver of software maintenance costs. This is almost always not the primary goal of a maintenance release. In this case, the amount of technical debt will still be a driver, though most likely not as significant. How does your development team find balance between improving the functional quality of your applications vs. improving the structural quality? How does awareness of technical debt inform your software maintenance estimates?