intro_chapter3.tex

Software companies and organizations have a common goal when developing software projects - to deliver high-quality, useful software in a timely manner. However, in most practical settings developers and development companies are saddled with deadlines, urging them to release earlier than the ideal date in terms of product quality. Such situations are all too common and in many cases force developers to take shortcuts \cite{kruchten2013technical} \cite{seaman2015technical}. Recently, the term \emph{technical debt} was coined to represent the phenomenon of ``doing something that is beneficial in the short term but will incur a cost later on''~ \cite{cunningham1993wycash}. Prior work has shown that there are many different reasons why practitioners assume technical debt. These reasons include: a rush to deliver a software product given a tight schedule, deadlines to incorporate with a partner product before release, time-to-market pressure, as well as meeting customer demands in a time-sensitive industry~\cite{lim2012balancing}.


% People studied different aspects of TD
More recently, a study by Potdar and Shihab \cite{ICSM_PotdarS14} introduced a new way to identify technical debt through source code comments, referred to as self-admitted technical debt (SATD). SATD is technical debt that developers themselves report through source code comments. Prior work \cite{MTD15p9} has demonstrated that accrual of SATD is commonplace in software projects, where its implementation can identify different types of technical debt (e.g., design, defect, and requirement debt).

Intuition and general belief concur that such rushed development tasks (also known as technical debt) negatively impact software maintenance and overall quality~\cite{zazworka2011investigating,spinola2013investigating,GuoSGCTSSS11,seaman2015technical,kruchten2013technical}. However, to the best of our knowledge, there is no empirical study that examines the impact of SATD on software quality. Such a study is critical since it will help us (i) confirm or refute entrenched preconceptions regarding the technique and (ii) better understand how to manage SATD.

% In this paper we do 1, 2,3
Therefore, in this thesis, we empirically investigate the relation between SATD and software quality in forty-five open-source projects. In particular, we examine whether (i) files with SATD have more defects compared to files without SATD, (ii) whether SATD changes introduce future defects, and (iii) whether SATD-related changes tend to be more difficult. We measured the difficulty of a change in terms of the amount of churn, the number of files, the number of modified modules in a change, as well as, entropy of a change. We perform our study on forty-five open-source projects. Our findings show that: i) there is no clear relationship between defects and SATD. While it is true that SATD files have more bug-fixing changes in a number of the studied projects, in other projects, files without SATD have more defects, ii) SATD changes are associated with less future defects than non-technical debt changes, yet iii) SATD changes (i.e., changes touching SATD files) are more difficult to perform. Our study indicates that although technical debt may have negative effects, its impact is not related to defects, rather its impact is in making the system more difficult to change in the future.