Measuring Technical Debt is not a single metric.  There are many factors that come into play, most are not visible to the leadership or within the product development lifecycle unless these metrics are specifically called out for in the process.  Added to this Technical Debt Visibility issue is the addition of newer development models such as Agile.  These models foster speed and agility, but if implemented by the unaware remove visibility to the Debt created.   Add market, customer, and management pressure for faster delivery and one can create condition to take shortcuts rationalizing that once in production the team will go back and correct. 

However, rarely does this happen.  The results are the team is then rushed to the next project and next and so on.  Addressing issues is left to the helpdesk, operations team or escalated back to software development team to patch quickly to get the application back online.  Over time this can create a bowl of spaghetti code, thus increasing one aspect of Technical Debt.

The problem can and often is pushed down to developers. “We have a code quality problem” Sound familiar?  When the truth is much broader than that.  Technical Debt is a Process Quality Issue. 

Often the issues start at the program planning and requirement phase.  We all have heard the manager’s rule of thumb of 80/20 or the like.  If you spend 20 hours gather requirements it will take 80 hours to code.  Thus, with a deadline management often pushes to finish the requirements and design phase quickly.  This is where the first bit of debt is created. 

Hidden in that rush a complete understand of how the software is to function and the context it must operate in now and in the future is missed.  Thus, alternatives are not explored in the rush to create utility, warrantee is often missed.  In other industries and disciplines these lessons have been had learned.  The cost of failure can be catastrophic or financially devastating[1] at best.

This quality issue is compounded with each step in the lifecycle till operationally all that is left is application utility for the immediate, leaving the minimal warrantee and Technical Debt such causes to grow hidden over time till a situation or scenario causes it to explode.  

[1] AA, Southwest, and other Software failures that have devastated enterprises.