SearcharxivSearch

arXiv subjects

Ehsan Zabardast

Publications and source records attributed to Ehsan Zabardast.

14 recordsLinked to original sources

The Dependency Black Hole

Microservice architectures promise independent evolution through loose coupling, yet large systems often exhibit strong dependency concentration around a small set of services. In an exploratory industrial case study of a product composed of 267 microservices, we triangulated multiple dependency signals -- compile-time, run-time, and task dependencies -- and iteratively validated our interpretations with practitioners. We observed a recurring macro-structure in the dependency network that resembles a black hole: a dense core of dependency magnets, a transitional region of services increasingly entangled with the core, and an outer region of lightly connected services. Based on these observations, we propose the dependency black hole theory, mapping the network to the black hole anatomy of a singularity, an event horizon, and an accretion disk, and formulating three hypotheses about how dependency concentration emerges and evolves at scale. The theory provides an explanatory lens for reasoning about dependency growth, identifying services at risk of becoming dependency magnets, and motivating governance interventions. We outline practical implications and directions for longitudinal and multi-case validation.

cs.SE

Towards a Software Architecture Description for Tax Compliance

The internal reuse of software components owned by organizational units in different countries constitutes an implicit form of licensing that may be taxable under international regulations, making tax authorities an often overlooked stakeholder in software architecture. This study assesses to what extent a deliberately minimal software architecture description can make implicit cross-border licensing visible and interpretable for tax experts. We define a deliberately minimal architecture viewpoint based on components, dependencies, ownership, and jurisdiction, and construct a view for a large-scale industrial microservice software system comprising 2,518 components and 16,533 dependencies. The resulting architecture description is evaluated in a judgment study with four experienced tax auditors and tax advisors using semi-structured interviews. The results show that the software architecture description provides a structured, evidence-based starting point for identifying cross-border reuse and supports tax audit discussions. However, experts consistently report limitations, including mismatches between software engineering and legal notions of ownership, unclear jurisdictional assignments, and the perceived risk of interpreting dependency counts as indicators of economic value. These limitations persist despite detailed architectural data. We conclude that software architecture descriptions can expose structurally relevant reuse relationships but cannot, on their own, support the legally meaningful interpretations required for tax assessment, indicating a fundamental mismatch between architectural abstractions and taxation concepts.

cs.SE

Quo Vadis, Code Review? Exploring the Future of Code Review

Context: Code review has long been a core practice in collaborative software engineering. As automation becomes increasingly embedded in development workflows, the role and functioning of code review are subject to change. Objective: This study explores how professional developers anticipate the evolution of code review and identifies emerging tensions reflected in these expectations. Method: We conducted a cross-sectional survey with 100 developers across five software-driven companies. The survey captured estimates of current review time and reviewed artifacts, as well as anticipated changes over a five-year horizon. Open-ended questions invited reflections on the future of code review. Quantitative responses were analyzed descriptively, and open-ended responses were independently coded by multiple researchers using thematic analysis to identify recurring patterns in participant responses. Results: Practitioners expect code review to remain essential, anticipating stable or increased time investment and a broader range of reviewed artifacts over the next five years. In open-ended responses, many participants explicitly referenced AI and large language models (LLMs), describing increasing automation in both code authoring and reviewing, including scenarios in which automated systems operate in both roles. Conclusion: Our analysis suggests emerging tensions concerning understanding, accountability, and trust in automation-mediated code review. These tensions provide early empirical signals of socio-technical challenges and position code review as a concrete setting for examining the implications of LLM integration in collaborative software engineering.

cs.SE

Towards a Goal-Centric Assessment of Requirements Engineering Methods for Privacy by Design

Implementing privacy by design (PbD) according to the General Data Protection Regulation (GDPR) is met with a growing number of requirements engineering (RE) approaches. However, the question of which RE method for PbD fits best the goals of organisations remains a challenge. We report our endeavor to close this gap by synthesizing a goal-centric approach for PbD methods assessment. We used literature review, interviews, and validation with practitioners to achieve the goal of our study. As practitioners do not approach PbD systematically, we suggest that RE methods for PbD should be assessed against organisational goals, rather than process characteristics only. We hope that, when further developed, the goal-centric approach could support the development, selection, and tailoring of RE practices for PbD.

cs.SE

Privacy by Design: Aligning GDPR and Software Engineering Specifications with a Requirements Engineering Approach

Context: Consistent requirements and system specifications are essential for the compliance of software systems towards the General Data Protection Regulation (GDPR). Both artefacts need to be grounded in the original text and conjointly assure the achievement of privacy by design (PbD). Objectives: There is little understanding of the perspectives of practitioners on specification objectives and goals to address PbD. Existing approaches do not account for the complex intersection between problem and solution space expressed in GDPR. In this study we explore the demand for conjoint requirements and system specification for PbD and suggest an approach to address this demand. Methods: We reviewed secondary and related primary studies and conducted interviews with practitioners to (1) investigate the state-of-practice and (2) understand the underlying specification objectives and goals (e.g., traceability). We developed and evaluated an approach for requirements and systems specification for PbD, and evaluated it against the specification objectives. Results: The relationship between problem and solution space, as expressed in GDPR, is instrumental in supporting PbD. We demonstrate how our approach, based on the modeling GDPR content with original legal concepts, contributes to specification objectives of capturing legal knowledge, supporting specification transparency, and traceability. Conclusion: GDPR demands need to be addressed throughout different levels of abstraction in the engineering lifecycle to achieve PbD. Legal knowledge specified in the GDPR text should be captured in specifications to address the demands of different stakeholders and ensure compliance. While our results confirm the suitability of our approach to address practical needs, we also revealed specific needs for the future effective operationalization of the approach.

cs.SE

The Upper Bound of Information Diffusion in Code Review

Background: Code review, the discussion around a code change among humans, forms a communication network that enables its participants to exchange and spread information. Although reported by qualitative studies, our understanding of the capability of code review as a communication network is still limited. Objective: In this article, we report on a first step towards evaluating the capability of code review as a communication network by quantifying how fast and how far information can spread through code review: the upper bound of information diffusion in code review. Method: In an in-silico experiment, we simulate an artificial information diffusion within large (Microsoft), mid-sized (Spotify), and small code review systems (Trivago) modelled as communication networks. We then measure the minimal topological and temporal distances between the participants to quantify how far and how fast information can spread in code review. Results: An average code review participants in the small and mid-sized code review systems can spread information to between 72% and 85% of all code review participants within four weeks independently of network size and tooling; for the large code review systems, we found an absolute boundary of about 11000 reachable participants. On average (median), information can spread between two participants in code review in less than five hops and less than five days. Conclusion: We found evidence that the communication network emerging from code review scales well and spreads information fast and broadly, corroborating the findings of prior qualitative work. The study lays the foundation for understanding and improving code review as a communication network.

cs.SE

Exploring the Relationship Between Ownership and Contribution Alignment and Code Technical Debt

Software development organisations aim to stay effective and efficient amid growing system complexity. To address this, they often form small teams focused on separate components that can be independently developed, tested, and deployed. Aligning architecture with organisational structures is crucial for effective communication and collaboration, reducing code and architectural degradation. Assigning specific component responsibility to the teams primarily working on them is key to these goals. This article explores the relationship between ownership and contribution alignment and code quality degradation, measured as technical debt per line of code. It also examines how team structure changes impact their ability to manage code quality degradation. We conducted a case study in a company developing a large software system, analysing ten components managed by one team. This team was later split into two, redistributing components between the new teams. Archival data from development tools used in their daily operations was collected. Before the split, there was a statistically significant negative correlation between contribution alignment and technical debt density in four components, indicating that higher contribution alignment leads to lower technical debt density and better code quality. After the split, this negative correlation persisted in three components, while five components showed a positive correlation, suggesting that low contribution alignment might worsen code quality degradation. Our findings suggest that contribution alignment is important in controlling code quality degradation in software development organisations. Ensuring teams are responsible for components they are most familiar with and minimising dependencies between teams can help mitigate code quality degradation.

cs.SE

Measuring Information Diffusion in Code Review at Spotify

Background: As a core practice in software engineering, the nature of code review has been frequently subject to research. Prior exploratory studies found that code review, the discussion around a code change among humans, forms a communication network that enables its participants to exchange and spread information. Although popular in software engineering, there is no confirmatory research corroborating this theory and the actual extent of information diffusion in code review is not well understood. Objective: In this registered report, we propose an observational study to measure information diffusion in code review to test the theory of code review as communication network. Method: We approximate the information diffusion in code review through the frequency and the similarity between (1) human participants, (2) affected components, and (3) involved teams of linked code reviews. The measurements approximating the information diffusion in code review serve as a foundation for falsifying the theory of code review as communication network.

cs.SE

Towards Measuring the Impact of Technical Debt on Lead Time: An Industrial Case Study

Background: Software companies must balance fast value delivery with quality, a trade-off that can introduce technical debt and potentially waste developers' time. As software systems evolve, technical debt tends to increase. However, estimating its impact on lead time still requires more empirical and experimental evidence. Objective: We conduct an empirical study investigating whether technical debt impacts lead time in resolving Jira issues. Furthermore, our aim is to measure the extent to which variance in lead time is explainable by the technical debt. Method: We conducted an industrial case study to examine the relationship in six components, each of which was analyzed individually. Technical debt was measured using SonarQube and normalized with the component's size, while lead time to resolve Jira issues was collected directly from Jira. Results: We found a set of mixed results. Technical debt had a moderate positive impact on lead time in two components, while we did not see a meaningful impact on two others. A moderate negative impact was found in the remaining two components. Conclusion: The findings show that technical debt alone can not explain all the variance in lead time, which ranges from 5% up to 41% across components. So, there should be some other variables (e.g., size of the changes made, complexity, number of teams involved, component ownership) impacting lead time, or it might have a residual effect that might manifest later on. Further investigation into those confounding variables is essential.

cs.SE

Taxing Collaborative Software Engineering

The engineering of complex software systems is often the result of a highly collaborative effort. However, collaboration within a multinational enterprise has an overlooked legal implication when developers collaborate across national borders: It is taxable. In this article, we discuss the unsolved problem of taxing collaborative software engineering across borders. We (1) introduce the reader to the basic principle of international taxation, (2) identify three main challenges for taxing collaborative software engineering making it a software engineering problem, and (3) estimate the industrial significance of cross-border collaboration in modern software engineering by measuring cross-border code reviews at a multinational software company.

cs.SE

A Taxonomy of Assets for the Development of Software-Intensive Products and Services

Context: Developing software-intensive products or services usually involves a plethora of software artefacts. Assets are artefacts intended to be used more than once and have value for organisations; examples include test cases, code, requirements, and documentation. During the development process, assets might degrade, affecting the effectiveness and efficiency of the development process. Therefore, assets are an investment that requires continuous management. Identifying assets is the first step for their effective management. However, there is a lack of awareness of what assets and types of assets are common in software-developing organisations. Most types of assets are understudied, and their state of quality and how they degrade over time have not been well-understood. Method: We perform a systematic literature review and a field study at five companies to study and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy. Results: We create the first comprehensive, structured, yet extendable taxonomy of assets, containing 57 types of assets. Conclusions: The taxonomy serves as a foundation for identifying assets that are relevant for an organisation and enables the study of asset management and asset degradation concepts.

cs.SE

Assets in Software Engineering: What are they after all?

During the development and maintenance of software-intensive products or services, we depend on various artefacts. Some of those artefacts, we deem central to the feasibility of a project and the product's final quality. Typically, these central artefacts are referred to as assets. However, despite their central role in the software development process, little thought is yet invested into what eventually characterises as an asset, often resulting in many terms and underlying concepts being mixed and used inconsistently. A precise terminology of assets and related concepts, such as asset degradation, are crucial for setting up a new generation of cost-effective software engineering practices. In this position paper, we critically reflect upon the notion of assets in software engineering. As a starting point, we define the terminology and concepts of assets and extend the reasoning behind them. We explore assets' characteristics and discuss what asset degradation is as well as its various types and the implications that asset degradation might bring for the planning, realisation, and evolution of software-intensive products and services over time. We aspire to contribute to a more standardised definition of assets in software engineering and foster research endeavours and their practical dissemination in a common, more unified direction.

cs.SE

Further Investigation of the Survivability of Code Technical Debt Items

Context: Technical Debt (TD) discusses the negative impact of sub-optimal decisions to cope with the need-for-speed in software development. Code Technical Debt Items (TDI) are atomic elements of TD that can be observed in code artefacts. Empirical results on open-source systems demonstrated how code-smells, which are just one type of TDIs, are introduced and "survive" during release cycles. However, little is known about whether the results on the survivability of code-smells hold for other types of code TDIs (i.e., bugs and vulnerabilities) and in industrial settings. Goal: Understanding the survivability of code TDIs by conducting an empirical study analysing two industrial cases and 31 open-source systems from Apache Foundation. Method: We analysed 133,670 code TDIs (35,703 from the industrial systems) detected by SonarQube (in 193,196 commits) to assess their survivability using survivability models. Results: In general, code TDIs tend to remain and linger for long periods in open-source systems, whereas they are removed faster in industrial systems. Code TDIs that survive over a certain threshold tend to remain much longer, which confirms previous results. Our results also suggest that bugs tend to be removed faster, while code smells and vulnerabilities tend to survive longer.

cs.SE

Experiential Learning Approach for Software Engineering Courses at Higher Education Level

Background: Software project management activities help to introduce software process models in Software Engineering courses. However, these activities should be adequately aligned with the learning outcomes and support student's progression. Objective: Present and evaluate an approach to help students acquire theoretical and practical knowledge and experience real-world software projects' challenges. The approach combines a serious game and a design-implement task in which students develop a controlled-scale software system. Method: To evaluate our approach, we analyzed the students' perceptions collected through an online survey, their project plans, and their final reports using thematic analysis. Results: Results suggest that the approach promotes knowledge acquisition, enables students' progression, reinforces theoretical concepts, and is properly aligned with the course's learning outcomes. Conclusion: The approach seems to help to introduce software process models in Software Engineering courses. Our experience can also be inspiring for educators willing to apply our approach in similar courses.

cs.SE