Technical Debt Repayment in Practice

Abstract

Technical Debt (TD) is a metaphor used to describe a trade-off between the shortterm benefits of "cutting corners" in software development and the long-term sustainability of a software system. Researchers have classified technical debt into several different types, such as design or code debt. The amount of technical debt tends to increase during the evolution of software systems. When the increasing technical debt results in extra maintenance and evolution effort, it needs to be (at least partially) managed.Technical debt repayment is the TD management activity which refers to the remediation of technical debt by reworking design and implementation constructs. Paying back all technical debt may be infeasible since there is typically a shortage of resources that can be allocated. Moreover, business stakeholders often prioritize resources (money and time) on developing new features and fixing defects, rather than performing TD refactoring activities. Therefore, developers need to improve resource allocation for TD repayment due to the limited resources and competing business interests. Thus, investigating the factors that influence TD repayment is crucial in finding optimal solutions that maximize value and satisfy resource constraints. The thesis reports on the investigation of how TD is paid back in practice and what factors influence this repayment, by considering both software repositories and the perspective of practitioners.In order to address the stated problem, we first looked into how TD repayment occurs in practice and its evolution over time. Specifically, we focused on the TD fixing rate across projects and across issue types, the repayment effort and the survival time of TD items. The results showed that most of the repayment effort goes into improving testing, adding documentation, reducing complexity, and removing duplication. We also extended a previous study on the same topic that used several Java projects and compared the results of TD remediation in Python and Java perspectief kan niet grondig onderzocht worden door naar een enkele gegevensbron te kijken (bijv. broncode of gesprekken van ontwikkelaars). Daarom hebben we gekeken naar twee gegevensbronnen (issue trackers en broncode) om de tijdlijn te onderzoeken van TD items die ontstaan in broncode, gerapporteerd en besproken worden in issue trackers en vervolgens terugbetaald worden in broncode. Daarvoor hebben we 219 TD-items uit vijf open-sourceprojecten handmatig geëxtraheerd en geïnspecteerd.De resultaten toonden aan dat de meeste TD-items die in issue trackers geïdentificeerd en als opgelost vermeld worden, ook terugbetaald worden in broncode, terwijl ongeveer een vijfde verder besproken wordt nadat ze geïdentificeerd zijn. De opgeloste TD items in issue trackers gerelateerd aan Design Debt hebben een significant hogere kans om terugbetaald te worden in broncode, terwijl Test Debt items minder kans hebben. Bovendien, hoewel het lang duurt om TD items te identificeren (ongeveer een jaar), hebben ze de neiging om binnen een paar dagen daar...