@article {SAN17,
	title = {Empirical Study on Refactoring Large-scale Industrial Systems and Its Effects on Maintainability},
	journal = {Journal of Systems and Software},
	volume = {129},
	number = {C},
	year = {2017},
	month = {jul},
	pages = {107{\textendash}126},
	abstract = {We examine hundreds of manual refactoring commits from large-scale industrial systems.We study the effects of these commits on source code using a maintainability model.Developers preferred to fix concrete coding issues rather than fix code smells.A single refactoring had only a small impact (sometimes even negative effect).Whole refactoring process has significant beneficial effect on the maintainability. Software evolves continuously, it gets modified, enhanced, and new requirements always arise. If we do not spend time occasionally on improving our source code, its maintainability will inevitably decrease. The literature tells us that we can improve the maintainability of a software system by regularly refactoring it. But does refactoring really increase software maintainability? Can it happen that refactoring decreases the maintainability? Empirical studies show contradicting answers to these questions and there have been only a few studies which were performed in a large-scale, industrial context. In our paper, we assess these questions in an in vivo context, where we analyzed the source code and measured the maintainability of 6 large-scale, proprietary software systems in their manual refactoring phase. We analyzed 2.5 million lines of code and studied the effects on maintainability of 315 refactoring commits which fixed 1273 coding issues. We found that single refactorings only make a very little difference (sometimes even decrease maintainability), but a whole refactoring period, in general, can significantly increase maintainability, which can result not only in the local, but also in the global improvement of the code.},
	keywords = {Antipatterns, coding issues, ISO/IEC 25010, maintainability, refactoring, select:quality, software quality},
	issn = {0164-1212},
	doi = {10.1016/j.jss.2016.08.071},
	url = {http://www.sciencedirect.com/science/article/pii/S0164121216301558?via\%3Dihub},
	author = {Sz{\H o}ke, G{\'a}bor and Antal, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@conference {FHF15,
	title = {Code Ownership: Impact on Maintainability},
	booktitle = {Proceedings of the 15th International Conference on Computational Science and Its Applications (ICCSA 2015)},
	series = {Lecture Notes in Computer Science (LNCS)},
	volume = {9159},
	year = {2015},
	month = {jun},
	pages = {3{\textendash}19},
	publisher = {Springer-Verlag},
	organization = {Springer-Verlag},
	address = {Banff, Alberta, Canada},
	abstract = {Software systems erode during development, which results in high maintenance costs in the long term. Is it possible to narrow down where exactly this erosion happens? Can we infer the future erosion based on past code changes? In this paper we investigate code ownership and show that a further step of code quality decrease is more likely to happen due to the changes in source files modified by several developers in the past, compared to files with clear ownership. We estimate the level of code ownership and maintainability changes for every commit of three open-source and one proprietary software systems. With the help of Wilcoxon rank test we compare the ownership values of the files in commits resulting maintainability increase with those of decreasing the maintainability. Three tests out of the four gave strong results and the fourth one did not contradict them either. The conclusion of this study is a generalization of the already known fact that common code is more error-prone than those of developed by fewer developers. This result could be utilized in identifying the {\textquotedblleft}hot spots{\textquotedblright} of the source code from maintainability point of view. A possible IDE plug-in, which indicates the risk of decreasing the maintainability of the source code, could help the architect and warn the developers.},
	keywords = {Code ownership, ISO/IEC 25010, Source code maintainability, Wilcoxon test},
	doi = {10.1007/978-3-319-21413-9_1},
	url = {https://link.springer.com/chapter/10.1007\%2F978-3-319-21413-9_1},
	author = {Farag{\'o}, Csaba and P Heged{\H u}s and Rudolf Ferenc}
}
@conference {FHF15b,
	title = {Cumulative Code Churn: Impact on Maintainability},
	booktitle = {Proceedings of the 15th IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM 2015)},
	year = {2015},
	month = {sep},
	pages = {141{\textendash}150},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Bremen, Germany},
	abstract = {It is a well-known phenomena that the source code of software systems erodes during development, which results in higher maintenance costs in the long term. But can we somehow narrow down where exactly this erosion happens? Is it possible to infer the future erosion based on past code changes? Do modifications performed on frequently changing code have worse effect on software maintainability than those affecting less frequently modified code? In this study we investigated these questions and the results indicate that code churn indeed increases the pace of code erosion. We calculated cumulative code churn values and maintainability changes for every version control commit operation of three open-source and one proprietary software system. With the help of Wilcoxon rank test we compared the cumulative code churn values of the files in commits resulting maintainability increase with those of decreasing the maintainability. In the case of three systems the test showed very strong significance and in one case it resulted in strong significance (p-values 0.00235, 0.00436, 0.00018 and 0.03616). These results support our preliminary assumption that modifying high-churn code is more likely to decrease the overall maintainability of a software system, which can be thought of as the generalization of the already known phenomena that code churn results in higher number of defects.},
	keywords = {code churn, ISO/IEC 25010, Source code maintainability, Wilcoxon test},
	doi = {10.1109/SCAM.2015.7335410},
	url = {http://ieeexplore.ieee.org/document/7335410/},
	author = {Farag{\'o}, Csaba and P Heged{\H u}s and Rudolf Ferenc}
}
@conference {SNH15,
	title = {Do Automatic Refactorings Improve Maintainability? An Industrial Case Study},
	booktitle = {Proceedings of the 31st International Conference on Software Maintenance and Evolution (ICSME 2015)},
	year = {2015},
	pages = {429{\textendash}438},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Bremen, Germany},
	abstract = {Refactoring is often treated as the main remedy against the unavoidable code erosion happening during software evolution. Studies show that refactoring is indeed an elemental part of the developers{\textquoteright} arsenal. However, empirical studies about the impact of refactorings on software maintainability still did not reach a consensus. Moreover, most of these empirical investigations are carried out on open-source projects where distinguishing refactoring operations from other development activities is a challenge in itself. We had a chance to work together with several software development companies in a project where they got extra budget to improve their source code by performing refactoring operations. Taking advantage of this controlled environment, we collected a large amount of data during a refactoring phase where the developers used a (semi)automatic refactoring tool. By measuring the maintainability of the involved subject systems before and after the refactorings, we got valuable insights into the effect of these refactorings on large-scale industrial projects. All but one company, who applied a special refactoring strategy, achieved a maintainability improvement at the end of the refactoring phase, but even that one company suffered from the negative impact of only one type of refactoring.},
	keywords = {automatic refactoring, coding issues, ISO/IEC 25010, Software maintainability},
	doi = {10.1109/ICSM.2015.7332494},
	url = {http://ieeexplore.ieee.org/document/7332494/},
	author = {Sz{\H o}ke, G{\'a}bor and Csaba Nagy and P Heged{\H u}s and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@conference {LTF15,
	title = {A Software Quality Model for {RPG}},
	booktitle = {Proceedings of the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2015)},
	year = {2015},
	month = {mar},
	pages = {91{\textendash}100},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Montr{\'e}al, Canada},
	abstract = {The IBM i mainframe was designed to manage business applications for which the reliability and quality is a matter of national security. The RPG programming language is the most frequently used one on this platform. The maintainability of the source code has big influence on the development costs, probably this is the reason why it is one of the most attractive, observed and evaluated quality characteristic of all. For improving or at least preserving the maintainability level of software it is necessary to evaluate it regularly. In this study we present a quality model based on the ISO/IEC 25010 international standard for evaluating the maintainability of software systems written in RPG. As an evaluation step of the quality model we show a case study in which we explain how we integrated the quality model as a continuous quality monitoring tool into the business processes of a mid-size software company which has more than twenty years of experience in developing RPG applications.},
	keywords = {Case Study, IBM i mainframe, ISO/IEC 25010, RPG quality model, Software maintainability},
	doi = {10.1109/SANER.2015.7081819},
	url = {http://ieeexplore.ieee.org/document/7081819/},
	author = {Lad{\'a}nyi, Gergely and T{\'o}th, Zolt{\'a}n and Rudolf Ferenc and Keresztesi, Tibor}
}
@conference {SAN14,
	title = {Bulk Fixing Coding Issues and Its Effects on Software Quality: Is It Worth Refactoring?},
	booktitle = {Proceedings of the 14th IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM 2014)},
	year = {2014},
	month = {sep},
	pages = {95{\textendash}104},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Victoria, British Columbia, Canada},
	abstract = {The quality of a software system is mostly defined by its source code. Software evolves continuously, it gets modified, enhanced, and new requirements always arise. If we do not spend time periodically on improving our source code, it becomes messy and its quality will decrease inevitably. Literature tells us that we can improve the quality of our software product by regularly refactoring it. But does refactoring really increase software quality? Can it happen that a refactoring decreases the quality? Is it possible to recognize the change in quality caused by a single refactoring operation? In our paper, we seek answers to these questions in a case study of refactoring large-scale proprietary software systems. We analyzed the source code of 5 systems, and measured the quality of several revisions for a period of time. We analyzed 2 million lines of code and identified nearly 200 refactoring commits which fixed over 500 coding issues. We found that one single refactoring only makes a small change (sometimes even decreases quality), but when we do them in blocks, we can significantly increase quality, which can result not only in the local, but also in the global improvement of the code.},
	keywords = {Antipatterns, coding issues, ISO/IEC 25010, maintainability, software quality},
	doi = {10.1109/SCAM.2014.18},
	url = {http://ieeexplore.ieee.org/document/6975643/},
	author = {Sz{\H o}ke, G{\'a}bor and Antal, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@conference {LHF14,
	title = {The Connection of the Bug Density and Maintainability of Classes},
	booktitle = {8th International Workshop on Software Quality and Maintainability},
	series = {SQM},
	year = {2014},
	note = {Presentation only},
	month = {feb},
	address = {Antwerp, Belgium},
	abstract = {Measuring software product maintainability is a central issue in software engineering which led to a number of different practical quality models. Besides system level assessments it is also desirable that these models provide technical quality information at source code element level (e.g. classes, methods) to aid the improvement of the software. Although many existing models give an ordered list of source code elements that should be improved, it is unclear how these improvements affect other important quality indicators of the system, e.g. bug density. In this paper we empirically investigate the connection of bug numbers in the classes of different open-source systems and the class level maintainability measures of our ColumbusQM probabilistic quality model using open-access bug datasets. We show that classes with lower maintainability score contain significantly more bugs than more maintainable classes. Moreover, in terms of correctness and completeness, ColumbusQM competes with statistical and machine learning prediction models especially trained on the bug data using product metrics as predictors. This is a great achievement in the light of that our model needs no training and its purpose is different (e.g. to estimate testability, or development costs) than those of the bug prediction models. In summary, we show that improving the maintainability of a software according to the suggestions of our quality model will expectedly also reduce its bug density.},
	keywords = {Bug density, Bug prediction, Class level maintainability, ColumbusQM, ISO/IEC 25010, Software maintainability},
	author = {Lad{\'a}nyi, Gergely and P Heged{\H u}s and Rudolf Ferenc and Istv{\'a}n Siket and Tibor Gyim{\'o}thy}
}
@conference {BaF14,
	title = {Recognizing Antipatterns and Analyzing Their Effects on Software Maintainability},
	booktitle = {Proceedings of the 14th International Conference on Computational Science and Its Applications (ICCSA 2014)},
	series = {Lecture Notes in Computer Science (LNCS)},
	volume = {8583},
	year = {2014},
	month = {jun},
	pages = {337{\textendash}352},
	publisher = {Springer-Verlag},
	organization = {Springer-Verlag},
	address = {Guimar{\~a}es, Portugal},
	abstract = {Similarly to design patterns and their inherent extra information about the structure and design of a system, antipatterns - or bad code smells - can also greatly influence the quality of software. Although the belief that they negatively impact maintainability is widely accepted, there are still relatively few objective results that would support this theory. In this paper we show our approach of detecting antipatterns in source code by structural analysis and use the results to reveal connections among antipatterns, number of bugs, and maintainability. We studied 228 open-source Java based systems and extracted bug-related information for 34 of them from the PROMISE database. For estimating the maintainability, we used the ColumbusQM probabilistic quality model. We found that there is a statistically significant, 0.55 Spearman correlation between the number of bugs and the number of antipatterns. Moreover, there is an even stronger, -0.62 reverse Spearman correlation between the number of antipatterns and code maintainability. We also found that even these few implemented antipatterns could nearly match the machine learning based bug-predicting power of 50 class level source code metrics. Although the presented analysis is not conclusive by far, these first results suggest that antipatterns really do decrease code quality and can highlight spots that require closer attention.},
	keywords = {Antipatterns, Empirical validation, ISO/IEC 25010, OO design, Software maintainability, SQuaRE},
	doi = {10.1007/978-3-319-09156-3_25},
	url = {https://link.springer.com/chapter/10.1007\%2F978-3-319-09156-3_25},
	author = {D{\'e}nes B{\'a}n and Rudolf Ferenc}
}
