On the diffuseness of code technical debt in Java projects of the apache ecosystem

Background. Companies commonly invest majorBackground. Companies commonly invest major effort into removing, respectively not introducing, technical debt issues detected by static analysis tools such as SonarQube, Cast, or Coverity. These tools classify technical debt issues into categories according to severity, and developers commonly pay attention to not introducing issues with a high level of severity that could generate bugs or make software maintenance more difficult. Objective. In this work, we aim to understand the diffuseness of Technical Debt (TD) issues and the speed with which developers remove them from the code if they introduced such an issue. The goal is to understand which type of TD is more diffused and how much attention is paid by the developers, as well as to investigate whether TD issues with a higher level of severity are resolved faster than those with a lower level of severity. We conducted a case study across 78K commits of 33 Java projects from the Apache Software Foundation Ecosystem to investigate the distribution of 1.4M TD items. Results. TD items introduced into the code are mostly related to code smells (issues that can increase the maintenance effort). Moreover, developers commonly remove the most severe issues faster than less severe ones. However, the time needed to resolve issues increases when the level of severity increases (minor issues are removed faster that blocker ones). Conclusion. One possible answer to the unexpected issue of resolution time might be that severity is not correctly defined by the tools. Another possible answer is that the rules at an intermediate severity level could be the ones that technically require more time to be removed. The classification of TD items, including their severity and type, require thorough investigation from a research point of view.effort into removing, respectively not introducing, technical debtissues detected by static analysis tools such as SonarQube, Cast, or Coverity. These tools classify technical debt issues intocategories according to severity, and developers commonly payattention to not introducing issues with a high level of severitythat could generate bugs or make software maintenance moredifficult. Objective. In this work, we aim to understand the diffuseness ofTechnical Debt (TD) issues and the speed with which developersremove them from the code if they introduced such an issue. The goal is to understand which type of TD is more diffusedand how much attention is paid by the developers, as well asto investigate whether TD issues with a higher level of severityare resolved faster than those with a lower level of severity. Weconducted a case study across 78K commits of 33 Java projectsfrom the Apache Software Foundation Ecosystem to investigatethe distribution of 1.4M TD items. Results. TD items introduced into the code are mostly relatedto code smells (issues that can increase the maintenance effort). Moreover, developers commonly remove the most severe issuesfaster than less severe ones. However, the time needed to resolveissues increases when the level of severity increases (minor issuesare removed faster that blocker ones). Conclusion. One possible answer to the unexpected issue ofresolution time might be that severity is not correctly definedby the tools. Another possible answer is that the rules at anintermediate severity level could be the ones that technicallyrequire more time to be removed. The classification of TD items, including their severity and type, require thorough investigationfrom a research point of view.

[1]  Apostolos Ampatzoglou,et al.  How do developers fix issues and pay back technical debt in the Apache ecosystem? , 2018, 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER).

[2]  Gabriele Bavota,et al.  When and Why Your Code Starts to Smell Bad (and Whether the Smells Go Away) , 2015, IEEE Transactions on Software Engineering.

[3]  Apostolos Ampatzoglou,et al.  The relation between technical debt and corrective maintenance in PHP web applications , 2017, Inf. Softw. Technol..

[4]  Eduardo Figueiredo,et al.  Understanding the longevity of code smells: preliminary results of an explanatory survey , 2011, WRT '11.

[5]  Harald C. Gall,et al.  Context is king: The developer perspective on the usage of static analysis tools , 2018, 2018 IEEE 25th International Conference on Software Analysis, Evolution and Reengineering (SANER).

[6]  Gabriele Bavota,et al.  On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation , 2017, Empirical Software Engineering.

[7]  Valentina Lenarduzzi,et al.  Does migrating a monolithic system to microservices decrease the technical debt? , 2019, J. Syst. Softw..

[8]  Alberto Sillitti,et al.  A Survey on Code Analysis Tools for Software Maintenance Prediction , 2018, SEDA.

[9]  Davide Taibi,et al.  How developers perceive smells in source code: A replicated study , 2017, Inf. Softw. Technol..

[10]  Ward Cunningham,et al.  The WyCash portfolio management system , 1992, OOPSLA '92.

[11]  Daniela Cruzes,et al.  The evolution and impact of code smells: A case study of two open source systems , 2009, 2009 3rd International Symposium on Empirical Software Engineering and Measurement.

[12]  Claus Pahl,et al.  Architectural Patterns for Microservices: A Systematic Mapping Study , 2018, CLOSER.

[13]  Jacob Cohen Statistical Power Analysis for the Behavioral Sciences , 1969, The SAGE Encyclopedia of Research Design.

[14]  Claus Pahl,et al.  Processes, Motivations, and Issues for Migrating to Microservices Architectures: An Empirical Investigation , 2017, IEEE Cloud Computing.

[15]  Sandro Morasca,et al.  Predicting OSS trustworthiness on the basis of elementary code assessment , 2010, ESEM '10.

[16]  Alberto Sillitti,et al.  Analyzing Forty Years of Software Maintenance Models , 2017, 2017 IEEE/ACM 39th International Conference on Software Engineering Companion (ICSE-C).

[17]  M. Patton,et al.  Qualitative evaluation and research methods , 1992 .

[18]  Paris Avgeriou,et al.  The Evolution of Technical Debt in the Apache Ecosystem , 2017, ECSA.

[19]  Davide Taibi,et al.  Does Migrate a Monolithic System to Microservices Decreases the Technical Debt? , 2019, ArXiv.

[20]  Davide Taibi,et al.  Architectural Smells Detected by Tools: a Catalogue Proposal , 2019, 2019 IEEE/ACM International Conference on Technical Debt (TechDebt).

[21]  Meiyappan Nagappan,et al.  Diversity in software engineering research , 2016, Perspectives on Data Science for Software Engineering.

[22]  Peng Liang,et al.  A systematic mapping study on technical debt and its management , 2015, J. Syst. Softw..

[23]  Foutse Khomh,et al.  Tracking Design Smells: Lessons from a Study of God Classes , 2009, 2009 16th Working Conference on Reverse Engineering.

[24]  Davide Taibi,et al.  On the Definition of Microservice Bad Smells , 2018, IEEE Software.

[25]  Raed Shatnawi,et al.  An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution , 2007, J. Syst. Softw..

[26]  Student An Experimental Determination of the Probable Error of Dr Spearman's Correlation Coefficients , 1921 .

[27]  Alexander Chatzigeorgiou,et al.  Investigating the Evolution of Bad Smells in Object-Oriented Code , 2010, 2010 Seventh International Conference on the Quality of Information and Communications Technology.

[28]  Mauricio A. Saca Refactoring improving the design of existing code , 2017, 2017 IEEE 37th Central America and Panama Convention (CONCAPAN XXXVII).

[29]  Sandro Morasca,et al.  An empirical investigation of perceived reliability of open source Java programs , 2012, SAC '12.