Do developers postpone fixing Technical Debt (TD) in software systems? TD is a metaphor that refers to short-term decisions in software development that may affect the cost of the software development life cycle. The bad smell is an imperfect solution in the software system that negatively impacts the internal software quality and maintainability. In this paper, we will study five open-source software projects (OSSPs) that have several releases and also estimate the numbers of architecture smells (ASs), design smells (DSs), and code smells (CSs) for every release. Designite will be used to detect smells. We describe a case study conducted to explore the following: (1) What is the average smells density for architecture, design, and code smells in an OSSP? (2) Does the density of each smell type increase over multiple releases? (3) What percentage of each smell-type density is eliminated by refactoring? We collected around 2 million LOC from five OSSPs that have multiple releases from the GitHub repository to statistically analyze the software concerning the smells as indicators of TD. We find 36% of Architecture Technical Debt (ATD) is Cyclic Dependency, while 33% of Design Debt (DD) is Cyclically-dependent Modularization. More than 70% of Code Debt (CD) is Magic Number. Even though the developers do refactoring between releases, the TD density in general increases. On average, by refactoring, developers remove around 48%, 16%, and 22% from the introduced ATD, DD, and CD from their next release, respectively.

Paying-off the Architectural Technical Debt by refactoring the flawed code is important to control the debt and to keep it as low as possible. Project Managers tend to delay paying off this debt because they face difficulties in comparing the cost of the refactoring against the benefits gained. These managers need to estimate the cost and the efforts required to conduct these refactoring activities as well as to decide which flaws have higher priority to be refactored. Our research is based on a dataset used by other researchers that study the technical debt. It includes more than 18,000 refactoring operations performed on 33 apache java projects. We applied the COCOMO II:2000 model to calculate the refactoring cost in person-months units per release. Furthermore, we investigated the correlation between the refactoring efforts and two static code metrics of the refactored code. The research revealed a weak correlation between the refactoring efforts and the size of the project, and a moderate correlation with the code complexity. Finally, we applied the DesigniteJava tool to verify our research results. From the analysis we found a significant correlation between the ranking of the architecture smells and the ranking of refactoring efforts for each package. Using machine learning practices, we took the architecture smells level and the code metrics of each release as an input to predict the levels of the refactoring effort of the next release. We calculated the results using our model and found that we can predict the ‘High’ and ‘Very High’ levels, the most significant levels from managers’ perspective, with [Formula: see text] accuracy.