@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}
}
