I recently finished writing my master's thesis on "the impact of self-admitted technical debt on software quality" [2], we use the same approach this article ad

I recently finished writing my master's thesis on "the impact of self-admitted technical debt on software quality" [2], we use the same approach this article advocates to identify this type of technical debt, which we call "self-admitted technical debt" (SATD) [1]. We examined the impact of SATD on software quality for forty open-source projects. To measure this, we took into account three criteria commonly associated with quality: (i) on the file level, the relationship between defects and SATD; (ii) on the change level, the potential of SATD to introduce future defects and (iii) the complexity SATD changes impose on the system. The results of our study indicate that: (i) SATD and defects exhibit no correlation at the file level, (ii) SATD changes make the system more susceptible to future defects than non-SATD changes do and (iii) SATD changes are more difficult to perform on the system. [2] (an abbreviated version [3]) There are more patterns to identify technical debt than "TODO, FIXME or XXX". You can find the rest of the patterns here [1]. It is very interesting to see developers confessing their workarounds and hacks through source code comments, as it can alert later contributors to the technical debt induced. References: [1] http://das.encs.concordia.ca/uploads/2016/01/Potdar_ICSME2014.pdf http://das.encs.concordia.ca/uploads/2016/01/Potdar_ICSME201... [2] https://www.scribd.com/document/345197805/Sultan-Wehaibi-master-s-thesis?secret_password=Zq5b32lVkHiyitBuQ1nQ https://www.scribd.com/document/345197805/Sultan-Wehaibi-mas... [3] http://das.encs.concordia.ca/uploads/2016/01/Wehaibi_SANER2016.pdf http://das.encs.concordia.ca/uploads/2016/01/Wehaibi_SANER20...