arXiv subjects

Rick Kazman

Publications and source records attributed to Rick Kazman.

29 records · Page 2Linked to original sources

arXiv2023

Building the MSR Tool Kaiaulu: Design Principles and Experiences

Background: Since Alitheia Core was proposed and subsequently retired, tools that support empirical studies of software projects continue to be proposed, such as Codeface, Codeface4Smells, GrimoireLab and SmartSHARK, but they all make different design choices and provide overlapping functionality. Aims: We seek to understand the design decisions adopted by these tools--the good and the bad--along with their consequences, to understand why their authors reinvented functionality already present in other tools, and to help inform the design of future tools. Method: We used action research to evaluate the tools, and to determine a set of principles and anti-patterns to motivate a new tool design. Results: We identified 7 major design choices among the tools: 1) Abstraction Debt, 2) the use of Project Configuration Files, 3) the choice of Batch or Interactive Mode, 4) Minimal Paths to Data, 5) Familiar Software Abstractions, 6) Licensing and 7) the Perils of Code Reuse. Building on the observed good and bad design decisions, we created our own tool architecture and implemented it as an R package. Conclusions: Tools should not require onerous setup for users to obtain data. Authors should consider the conventions and abstractions used by their chosen language and build upon these instead of redefining them. Tools should encourage best practices in experiment reproducibility by leveraging self-contained and readable schemas that are used for tool automation, and reuse must be done with care to avoid depending on dead code.

cs.SE↗

arXiv2023

An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps

Technical debt describes situations where developers write less-than-optimal code to meet project milestones. However, this debt accumulation often results in future developer effort to live with or fix these quality issues. To better manage this debt, developers may document their sub-optimal code as comments in the code (i.e., self-admitted technical debt or SATD). While prior research has investigated the occurrence and characteristics of SATD, this research has primarily focused on non-mobile systems. With millions of mobile applications (apps) in multiple genres available for end-users, there is a lack of research on sub-optimal code developers intentionally implement in mobile apps. In this study, we examine the occurrence and characteristics of SATD in 15,614 open-source Android apps. Our findings show that even though such apps contain occurrences of SATD, the volume per app (a median of 4) is lower than in non-mobile systems, with most debt categorized as Code Debt. Additionally, we identify typical elements in an app that are prone to intentional sub-optimal implementations. We envision our findings supporting researchers and tool vendors with building tools and techniques to support app developers with app maintenance.

cs.SE↗

arXiv2023

Towards the Assisted Decomposition of Large-Active Files

Tightly coupled and interdependent systems inhibit productivity by requiring developers to carefully coordinate their changes, even when modifying subsystems that should be independent of one another. Poor architectural decisions frequently lead to the presence of large, change-prone source files that are at the center of complexes of technical debt. This kind of technical debt quickly incurs interest both through coordination costs and error-proneness. In this paper, we present a new approach for decomposing these ``large-active'' files to pay down critical technical debt. We package our approach as a refactoring recommendation system. Each recommendation is determined by analyzing patterns of co-change and mutual dependency among files. Each recommendation corresponds to a responsibility the large-active file has in relation to the rest of the system. By moving recommended functionality from the large-active file into smaller files, developers can reduce the impact of a debt-laden file and clarify its essential responsibilities. A key advantage of this approach over prior work is that we better focus effort; we avoid spending developer effort refactoring code that is only superficially problematic. We achieve this by incorporating revision history into both determining and ranking recommendations. Each recommendation corresponds to some change-prone responsibility. We present some examples of this approach in action and outline our future plans.

cs.SE↗

arXiv2022

Towards a Maturity Model for Systematic Literature Review Process

Systematic literature reviews (SLR) have been increasingly conducted in software engineering and they provide significant benefits in terms of summarizing the state of the research. The process of conducting SLR is complex, involving several activities and consuming considerable effort and time from researchers. Researchers often skip or poorly conduct essential activities, which introduce threats to validity, resulting in lower-quality SLR. But researchers are often unaware of what they could do to mature their SLR process, thus improving the SLR quality. The main goal of this paper is to introduce a maturity model for the SLR process named MM4SLR. To this end, we were inspired by well-known models like CMMI (Capability Maturity Model Integration). We first identified 39 key practices for SLR from the literature and grouped them into nine goals that were further grouped into five process areas. We then organized the process areas into five maturity levels which compose our model. Our proof of concept, applying the MM4SLR to four published SLR showed that the MM4SLR is suitable for appraising SLR and can identify important flaws in SLR quality. MM4SLR can therefore support researchers in creating their SLR processes and selecting practices that could be adopted to mature their processes.

cs.SE↗

arXiv2021

In Search of Socio-Technical Congruence: A Large-Scale Longitudinal Study

We report on a large-scale empirical study investigating the relevance of socio-technical congruence over key basic software quality metrics, namely, bugs and churn. In particular, we explore whether alignment or misalignment of social communication structures and technical dependencies in large software projects influences software quality. To this end, we have defined a quantitative and operational notion of socio-technical congruence, which we call socio-technical motif congruence (STMC). STMC is a measure of the degree to which developers working on the same file or on two related files, need to communicate. As socio-technical congruence is a complex and multi-faceted phenomenon, the interpretability of the results is one of our main concerns, so we have employed a careful mixed-methods statistical analysis. In particular, we provide analyses with similar techniques as employed by seminal work in the field to ensure comparability of our results with the existing body of work. The major result of our study, based on an analysis of 25 large open-source projects, is that STMC is not related to project quality measures -- software bugs and churn -- in any temporal scenario. That is, we find no statistical relationship between the alignment of developer tasks and developer communications on the one hand, and project outcomes on the other hand. We conclude that, wherefore congruence does matter as literature shows, then its measurable effect lies elsewhere.

cs.SE↗

arXiv2021

Worst Smells and Their Worst Reasons

The aims of this paper are: 1) to identify "worst smells", i.e., bad smells that never have a good reason to exist, 2) to determine the frequency, change-proneness, and severity associated with worst smells, and 3) to identify the "worst reasons", i.e., the reasons for introducing these worst smells in the first place. To achieve these aims we ran a survey with 71 developers. We learned that 80 out of 314 catalogued code smells are "worst"; that is, developers agreed that these 80 smells should never exist in any code base. We then checked the frequency and change-proneness of these worst smells on 27 large Apache open-source projects. Our results show insignificant differences, in both frequency and change proneness, between worst and non-worst smells. That is to say, these smells are just as damaging as other smells, but there is never any justifiable reason to introduce them. Finally, in follow-up phone interviews with five developers we confirmed that these smells are indeed worst, and the interviewees proposed seven reasons for why they may be introduced in the first place. By explicitly identifying these seven reasons, project stakeholders can, through quality gates or reviews, ensure that such smells are never accepted in a code base, thus improving quality without compromising other goals such as agility or time to market.

cs.SE↗

arXiv2021

On the Lack of Consensus Among Technical Debt Detection Tools

A vigorous and growing set of technical debt analysis tools have been developed in recent years -- both research tools and industrial products -- such as Structure 101, SonarQube, and DV8. Each of these tools identifies problematic files using their own definitions and measures. But to what extent do these tools agree with each other in terms of the files that they identify as problematic? If the top-ranked files reported by these tools are largely consistent, then we can be confident in using any of these tools. Otherwise, a problem of accuracy arises. In this paper, we report the results of an empirical study analyzing 10 projects using multiple tools. Our results show that: 1) these tools report very different results even for the most common measures, such as size, complexity, file cycles, and package cycles. 2) These tools also differ dramatically in terms of the set of problematic files they identify, since each implements its own definitions of "problematic". After normalizing by size, the most problematic file sets that the tools identify barely overlap. 3) Our results show that code-based measures, other than size and complexity, do not even moderately correlate with a file's change-proneness or error-proneness. In contrast, co-change-related measures performed better. Our results suggest that, to identify files with true technical debt -- those that experience excessive changes or bugs -- co-change information must be considered. Code-based measures are largely ineffective at pinpointing true debt. Finally, this study reveals the need for the community to create benchmarks and data sets to assess the accuracy of software analysis tools in terms of commonly used measures.

cs.SE↗

arXiv2020

Success and Failure in Software Engineering: a Followup Systematic Literature Review

Success and failure in software engineering are still among the least understood phenomena in the discipline. In a recent special journal issue on the topic, Mantyla et al. started discussing these topics from different angles; the authors focused their contributions on offering a general overview of both topics without deeper detail. Recognising the importance and impact of the topic, we have executed a followup, more in-depth systematic literature review with additional analyses beyond what was previously provided. These new analyses offer: (a) a grounded-theory of success and failure factors, harvesting over 500+ factors from the literature; (b) 14 manually-validated clusters of factors that provide relevant areas for success- and failure-specific measurement and risk-analysis; (c) a quality model composed of previously unmeasured organizational structure quantities which are germane to software product, process, and community quality. We show that the topics of success and failure deserve further study as well as further automated tool support, e.g., monitoring tools and metrics able to track the factors and patterns emerging from our study. This paper provides managers with risks as well as a more fine-grained analysis of the parameters that can be appraised to anticipate the risks.

cs.SE↗

arXiv2020

Organisational Structure Patterns in Agile Teams: An Industrial Empirical Study

Forming members of an organization into coherent groups or communities is an important issue in any large-scale software engineering endeavour, especially so in agile software development teams which rely heavily on self-organisation and organisational flexibility. To address this problem, many researchers and practitioners have advocated a strategy of mirroring system structure and organisational structure, to simplify communication and coordination of collaborative work. But what are the patterns of organisation found in practice in agile software communities and how effective are those patterns? We address these research questions using mixed-methods research in industry, that is, interview surveys, focus-groups, and delphi studies of agile teams. In our study of 30 agile software organisations we found that, out of 7 organisational structure patterns that recur across our dataset, a single organisational pattern occurs over 37% of the time. This pattern: (a) reflects young communities (1-12 months old); (b) disappears in established ones (13+ months); (c) reflects the highest number of architecture issues reported. Finally, we observe a negative correlation between a proposed organisational measure and architecture issues. These insights may serve to aid architects in designing not only their architectures but also their communities to best support their co-evolution.

cs.CY↗

arXiv2019

Microservice Transition and its Granularity Problem: A Systematic Mapping Study

Microservices have gained wide recognition and acceptance in software industries as an emerging architectural style for autonomic, scalable, and more reliable computing. The transition to microservices has been highly motivated by the need for better alignment of technical design decisions with improving value potentials of architectures. Despite microservices' popularity, research still lacks disciplined understanding of transition and consensus on the principles and activities underlying "micro-ing" architectures. In this paper, we report on a systematic mapping study that consolidates various views, approaches and activities that commonly assist in the transition to microservices. The study aims to provide a better understanding of the transition; it also contributes a working definition of the transition and technical activities underlying it. We term the transition and technical activities leading to microservice architectures as microservitization. We then shed light on a fundamental problem of microservitization: microservice granularity and reasoning about its adaptation as first-class entities. This study reviews state-of-the-art and -practice related to reasoning about microservice granularity; it reviews modelling approaches, aspects considered, guidelines and processes used to reason about microservice granularity. This study identifies opportunities for future research and development related to reasoning about microservice granularity.

cs.SE↗

arXiv2018

A Longitudinal Study of Identifying and Paying Down Architectural Debt

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and-dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.

cs.SE↗