How junior developers deal with their technical debt?

Abstract

Technical debt is a metaphor that measures the additional effort needed to continue to add more features in a software due to its inherent decrease in code quality. Most software systems suffer from technical debt at some point so that dedicated tools and metrics have been developed to monitor such debt. Alongside tools, appropriate engineering practices must be put in place by the development team to keep that debt at an acceptable level. In this empirical study, we observed and surveyed Scrum development teams composed of experienced students in order to understand their quality-related processes on a year-long academic project. We found that (1) students do use static analysis tools of many forms, but their actual usage is limited due to time pressure; (2) retrospective and non-constraining feedback on code quality has little to no effect, even when given regularly during the course of the project; and (3) junior developers value composite quality indicators (e.g., maintainability, reliability in SonarQube), even if they do not fully understand their meaning. From our findings, we propose a series of recommendations, both technical and methodological, on how to train junior developers to understand and manage technical debt. CCS CONCEPTS• Software and its engineering → Agile software development; Maintaining software; • Social and professional topics → Software engineering education;

Does it matter who pays back Technical Debt? An empirical study of self-fixed TD

“…There are also external factors that can affect how developers remediate technical debt, such as using tools. For example, Gilson et al [19] found that junior developers tend to use static analysis tools to value composite quality indicators (e.g., maintainability, reliability in SonarQube), even if they do not fully understand their meaning. However, Ernst et al [20] conducted a survey with 1831 participants, primarily software engineers and architects, and found that the lack of tool support for accurately managing and tracking architectural sources of debt is a key issue and remains a gap in practice.…”

Does it matter who pays back Technical Debt? An empirical study of self-fixed TD

“…There are also external factors that can affect how developers remediate technical debt, such as using tools. For example, Gilson et al [19] found that junior developers tend to use static analysis tools to value composite quality indicators (e.g., maintainability, reliability in SonarQube), even if they do not fully understand their meaning. However, Ernst et al [20] conducted a survey with 1,831 participants, primarily software engineers and architects, and found that the lack of tool support for accurately managing and tracking architectural sources of debt is a key issue and remains a gap in practice.…”

“…However, where tentative conclusions are still acceptable, α ≥ 0.67 is the lowest conceivable limit [53]. 19 https://github.com/jieshanshan/ist-si-sftd 32GB of RAM.…”

Technical Debt in the Peer-Review Documentation of R Packages: a rOpenSci Case Study

“…However, although it has a growing community, most package contributors are not software engineers by training [15], and only a few of them are mindful of the inner concepts of the language [18]. This lack of formal programming training can lead to lower code quality [19].…”