Introduction.tex

Technical debt is a metaphor in which the consequences of decisions that affect the maintenance of a software system, such as decisions regarding architecture and code structure, are described with attributes of financial debt~\cite{Cunningham:1992}. Economic models proposed by the \TD community quantify debt using the concepts of principal and interest, where principal is the cost to repay the debt by reworking the code and interest is the cost accumulated by developers working around the debt while the principal is not repaid.

Technical debt has several sources identified in the body of work including debt related to architecture, code structure, code complexity, and code smells~\cite{Ozkaya_etal:2012}.  In this work we focus on the area of technical debt related to code structure and code smells (i.e., poor code structure or quality).  Several approaches for estimating the \TD principal are based on heuristics that use measures of structural code quality as inputs to models that estimate effort. For example, Nugroho et al.~\cite{Nugroho_etal:2011} provide a model for estimating principal using maintainability ratings based on measures obtained via static analysis of code, and a model for estimating interest using estimates of maintenance effort based on change history of code. Curtis \etal~\cite{Curtis_etal:2012} also provide a model for estimating principal using measures based on static analysis of code, but in their model, principal is a function of the number of problems, the time/effort required to fix each problem, and the cost of fixing a problem.

Although such models provide the means to estimate debt, it may be difficult to justify reducing technical debt without detailed information about the impact of the debt on developer's day-to-day maintenance activities. Until the debt reaches a point at which it has a substantial impact on the progress or cost of maintenance, developers may be forced to work around areas of the code in which the debt is manifest~\cite{Ozkaya_etal:2011}. 
Because most developer effort during software maintenance is spent on program comprehension activities such as reading and navigating code~\cite{Fjeldstad_Hamlen:1982,Standish:1984,Ko_etal:2006,LaToza_etal:2006,Tiarks:2011}, understanding the impact of structural-quality-related debt on code comprehension is of critical importance. In this paper, we propose a framework to support continuous estimation of interest payments on technical debt by monitoring the effort that developers must expend to comprehend code as they complete change tasks. 

In our proposed framework, principal estimation is based on measures of code maintainability obtained via static analysis, and interest estimation is based on activity data obtained by monitoring developer actions in the IDE. Our monitoring tool, $Blaze$~\cite{Snipes_etal:2014}, records a temporal sequence of developer actions, including code navigation actions and edit actions, in a log. We analyze this log to understand class relationships and to quantify the effort spent by a developer to comprehend individual program elements while completing a change task. By combining this comprehension effort data with the code maintainability measurements, we can provide evidence of how \TD impacts developer-code-comprehension effort and continuously update interest payment estimates.

By continuously assessing the interest payments on technical debt, the framework enables teams to prioritize debt removal efforts in real-time.  Further, by measuring code comprehension on a per-class basis, we permit fine-grained analysis of the trade-off between repaying the debt by fixing the issues or continuing to pay the interest by  working around the debt. %\Fix{NK: I want to make the previous sentence more specific but am unsure of the original intent. Does the ``cost to implement a change'' refer to the principal or interest?}