by Arlene Minkiewicz
| August 27, 2015
Original Post Date: June 19, 2015
Ward Cunningham introduced the notion of technical debt in 1992, writing “Shipping first time code is like going into debt. A little debt speeds up development so long as it is paid back promptly with a rewrite”. Technical debt can be described as a quantification of the amount of ‘should fix’ issues that remain in production code. The term “technical debt” is a metaphor used to ease business leaders understanding of the costs of making poor decisions during development or making wise decisions during development (such as a short cut to meet a time to market goal) and not following up with a quick rewrite to address the short cut. It is intended to facilitate discussions between business leaders and the software development team. The notion of technical debt should help create a situation where the development team accepts the fact that certain business realities will sometimes create an environment where best practices and processes must be thrust aside and in concert with this, the business leaders understand that decisions to incur this ‘debt’ are only wise if there is also a plan in place to return the code to a proper state as soon as possible.
Technical debt is not the same as software quality, though there is certainly an intersection between software quality measures and characteristics that indicate technical debt. Software quality measures include indications of how well the software meets user requirements along with how well those requirements are delivered. Technical debt speaks to the structural quality of the software. An application that meets all the user requirements with a completely satisfactory user interface could be sitting on a mountain of technical debt if programming practices or coding standards were detoured, or methods and functions were poorly documented. Tools and methodologies that measure technical debt look for things such as uncommented methods, artifacts with high internal complexity, use of global variables, artifacts with high fan-out, duplicated code, inadequate test coverage, etc. Even an application developed using all best practices could amass technical debt over time if it is not evolving to keep up with current technology.
Clearly assessing the cost of addressing technical debt is not the same thing as determining the cost of maintaining a piece of software. There is however strong evidence that an understanding of an application’s technical debt potential should be an important piece of information when an estimate is being performed for the maintenance of that application. Much of what is considered technical debt speaks specifically to the things that will make the software harder to maintain and upgrade. For more on this topic check out my paper here.