Surveying Software Practitioners on Technical Debt Payment Practices and Reasons for not Paying off Debt Items

Rios, Nicolli; Gutierrez, Boris; Torres, Darío Ernesto Correal; Mendonça, Manoel; Izurieta, Clemente; Seaman, Carolyn; Spínola, Rodrigo O.

doi:10.1145/3383219.3383241

Cited by 35 publications

(21 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The other two most cited reasons for self-fixing TD are to avoid higher cost and improve maintainability, which indicate a consideration of the trade-off between cost and benefit in order to find the appropriate moment to self-fix TD. This result aligns with related findings that mentioned focus on short-term goals and cost as reasons when participants are considering whether or not to repay TD (Freire et al, 2020).…”

Section: Interpretation Of Resultssupporting

confidence: 92%

“…Due to the limited allocated resources for TD repayment, paying back all TD existing in a system is infeasible (Ampatzoglou et al, 2015;Guo et al, 2016;Alfayez et al, 2020;Freire et al, 2020). To support TD repayment, researchers have contributed various approaches, e.g., investigating how particular forms of debt such as self-admitted TD are paid back (Bavota and Russo, 2016;Maldonado et al, 2017) and how repayment relates to software quality metrics such as changeproneness (Palomba et al, 2018b) and maintenance effort (Sjøberg et al, 2013).…”

Section: Methodsmentioning

confidence: 99%

“…Do practitioners intentionally self-fix Technical Debt and why? low priority on the debt, focus on short-term goals, cost, and lack of time (Freire et al, 2020). In contrast to these studies, we focus on the reasons influencing developers' decisions to deal with their own debt, i.e., why they introduce and self-fix TD.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Technical Debt Repayment in Practice

Tan¹

View full text Add to dashboard Cite

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...

show abstract

Section: Interpretation Of Resultssupporting

confidence: 92%

Section: Methodsmentioning

confidence: 99%

See 1 more Smart Citation

Technical Debt Repayment in Practice

Tan¹

View full text Add to dashboard Cite

show abstract

“…Currently, researchers from Argentina, Brazil, Chile, Colombia, Costa Rica, Finland, Indian, Italy, Norway, Saudi Arabia, Serbia, and the United States have joined the project. Several results from InsighTD have been disseminated in the technical literature, reporting on causes and effects of TD [8][9][10][11][12][13], TD prevention [24], TD payment [25,26], and the relationship between effects and TD payment [27].…”

Section: The Insightd Projectmentioning

confidence: 99%

How Experience Impacts Practitioners' Perception of Causes and Effects of Technical Debt

Rios

Pérez

Castellanos

et al. 2021

2021 IEEE/ACM 13th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE)

Self Cite

View full text Add to dashboard Cite

Context: The technical debt (TD) metaphor helps to conceptualize the pending issues and trade-offs made during software development. Knowing TD causes can support in defining preventive actions and having information about effects aids in the prioritization of TD payment. Goal: To investigate the impact of the experience level on how practitioners perceive the most likely causes that lead to TD and the effects of TD that have the highest impacts on software projects. Method: We approach this topic by surveying 227 practitioners. Results: While experienced software developers focus on human factors as TD causes and external quality attributes as TD effects, low experienced developers seem to concentrate on technical issues as causes and internal quality issues and increased project effort as effects. Missing any of these types of causes could lead a team to miss the identification of important TD, or miss opportunities to preempt TD. On the other hand, missing important effects could hamper effective planning or erode the effectiveness of decisions about prioritizing TD items. Conclusion: Having software development teams composed of practitioners with a homogeneous experience level can erode the team's ability to effectively manage TD.

show abstract

“…Some SATD may also be accidentally removed when entire classes or methods are dropped [27]. Researchers have also investigated the reasons for not paying TD back, e.g., lack of organizational interest, low priority on the debt, focus on short-term goals, cost, and lack of time [28]. In contrast to these studies, we focus on the reasons influencing developers' decisions to deal with their own debt, i.e., why they introduce and self-fix TD.…”

Section: Related Workmentioning

confidence: 99%

Do practitioners intentionally self-fix Technical Debt and why?

Tan

Feitosa

Avgeriou

2021

2021 IEEE International Conference on Software Maintenance and Evolution (ICSME)

View full text Add to dashboard Cite

The impact of Technical Debt (TD) on software maintenance and evolution is of great concern, but recent evidence shows that a considerable amount of TD is fixed by the same developers who introduced it; this is termed self-fixed TD. This characteristic of TD management can potentially impact team dynamics and practices in managing TD. However, the initial evidence is based on low-level source code analysis; this casts some doubt whether practitioners repay their own debt intentionally and under what circumstances. To address this gap, we conducted an online survey on 17 well-known Java and Python open-source software communities to investigate practitioners' intent and rationale for self-fixing technical debt. We also investigate the relationship between human-related factors (e.g., experience) and self-fixing. The results, derived from the responses of 181 participants, show that a majority addresses their own debt consciously and often. Moreover, those with a higher level of involvement (e.g., more experience in the project and number of contributions) tend to be more concerned about self-fixing TD. We also learned that the sense of responsibility is a common self-fixing driver and that decisions to fix TD are not superficial but consider balancing costs and benefits, among other factors. The findings in this paper can lead to improving TD prevention and management strategies.

show abstract

Surveying Software Practitioners on Technical Debt Payment Practices and Reasons for not Paying off Debt Items

Cited by 35 publications

References 12 publications

Technical Debt Repayment in Practice

Technical Debt Repayment in Practice

How Experience Impacts Practitioners' Perception of Causes and Effects of Technical Debt

Do practitioners intentionally self-fix Technical Debt and why?

Contact Info

Product

Resources

About