Outside of performance-focused domains, research software is typically designed with output in mind rather than runtime efficiency. So, the resulting software consumes more resources (time, hardware) and is less scalable, hindering larger or longitudinal studies without adaptations. In this paper, we report our experiences of iteratively identifying and optimizing performance bottlenecks to enable such analyses in an established research software. Specifically, we applied a top-down strategy to Arcan, an architecture-smell detection tool, to develop a tool (AsTdEA) for tracing architecture smells through software evolution. To identify performance bottlenecks and benchmark our improvements, we used the Qualitas Corpus and a custom dataset. We achieved a reduction in processing time of approx. 98 % and reduced the runtime complexity from almost quadratic to close-to-linear. By sharing our process and insights, we hope to guide researchers in optimizing their research software in the future.

Architecture smells are a widely established concept to describe symptoms of software degradation by measuring perceived violations of software-design principles. As such, architecture smells can help developers assess and understand the architectural quality of their software system. However, research has rarely been concerned with how architecture smells evolve and whether they actually foster software degradation during a system’s evolution. Building on our previous work in this direction, we present extended techniques for measuring architecture smells, novel visualizations, as well as an empirical study of how architecture smells evolve and what typical patterns they exhibit in 485 releases of 14 open-source systems. Among others, the results of our study indicate that especially cyclic dependencies on the class-level are prone to becoming highly complex over time, with one of the reasons being the continued merging of smells, most often resulting in tangled multi-hubs. Moreover, we found unstable dependencies to mostly grow slowly over time, whereas hub-like dependencies remain rather stable during a system’s evolution. These findings are valuable for practitioners to identify and tackle system degeneration, as well as for researchers to scope new research on managing architecture smells and technical debt.

Architecture smells indicate violations of software-design principles. So, identifying and assessing architecture smells facilitates refactorings to reduce technical debt and ensure maintainability. Detecting architecture smells in only one version at a time provides a static and limited picture, since, for example, historical trends remain obfuscated. Both, for practitioners and researchers, obtaining information on how specific architecture smells evolved over time can yield valuable insights, be it for avoiding the growth of critical smells, grasping the code’s degradation, or getting a better understanding of development processes. To support such analyses, we developed our tool AsTdEA, which tracks architecture smells throughout a system’s evolution. AsTdEA runs a modified version of the architecture-smell detection tool Arcan and allows the automated batch-processing of multiple versions of one or multiple systems. First, AsTdEA generates data on the components that are involved in each smell on a version-to-version basis and how these intra-version smells are related with one another across the entire system history, forming inter-version smells. Second, for every intra-version smell, inter-version smell, and system version, AsTdEA outputs a multitude of properties, which we have already used for multiple empirical studies. In this paper, we show the implementation and use of AsTdEA, as well as the lessons that we learned during its development and how we want to improve it in the future.

If software quality assurance is postponed or even abandoned for a software system, maintenance and evolution become harder or even impossible. One widely known symptom for the degradation of system quality are Architecture Smells (ASs), which violate fundamental principles of software design. In this paper, we present a study on the evolution of ASs as well as on how and when they foster system degradation. Thus, we provide valuable insights regarding what ASs are meaningful to assure system quality. To this end, we analyzed the evolution of three types of ASs in 14 open-source systems with a total of 485 versions. We adapted indicators used in previous studies to assess the severity of ASs (e.g., growth, lifetime), and relate ASs to technical debt as another established indicator. Our results indicate that 1) ASs remain mostly stable compared to the code size of a system, 2) certain types of ASs, such as cyclic dependencies, have a greater impact on system degradation, and 3) certain properties determine how much an AS contributes to software degradation. These findings are valuable for practitioners to identify and tackle system degeneration, as well as for researchers to scope new research on managing ASs and technical debt.