SearcharxivSearch

arXiv subjects

Javier Gonzalez-Huerta

Publications and source records attributed to Javier Gonzalez-Huerta.

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

Reducing Friction in Cloud Migration of Services

Public cloud services are integral to modern software development, offering scalability and flexibility to organizations. Based on customer requests, a large product development organization considered migrating the microservice-based product deployments of a large customer to a public cloud provider. We conducted an exploratory single-case study, utilizing quantitative and qualitative data analysis to understand how and why deployment costs would change when transitioning the product from a private to a public cloud environment while preserving the software architecture. We also isolated the major factors driving the changes in deployment costs. We found that switching to the customer-chosen public cloud provider would increase costs by up to 50\%, even when sharing some resources between deployments, and limiting the use of expensive cloud services such as security log analyzers. A large part of the cost was related to the sizing and license costs of the existing relational database, which was running on Virtual Machines in the cloud. We also found that existing system integrators, using the product via its API, were likely to use the product inefficiently, in many cases causing at least 10\% more load to the system than needed. From a deployment cost perspective, successful migration to a public cloud requires considering the entire system architecture, including services like relational databases, value-added cloud services, and enabled product features. Our study highlights the importance of leveraging end-to-end usage data to assess and manage these cost drivers effectively, especially in environments with elastic costs, such as public cloud deployments.

cs.SE

Governing the Commons: Code Ownership and Code-Clones in Large-Scale Software Development

Context: In software development organizations employing weak or collective ownership, different teams are allowed and expected to autonomously perform changes in various components. This creates diversity both in the knowledge of, and in the responsibility for, individual components. Objective: Our objective is to understand how and why different teams introduce technical debt in the form of code clones as they change different components. Method: We collected data about change size and clone introductions made by ten teams in eight components which was part of a large industrial software system. We then designed a Multi-Level Generalized Linear Model (MLGLM), to illustrate the teams' differing behavior. Finally, we discussed the results with three development teams, plus line manager and the architect team, evaluating whether the model inferences aligned with what they expected. Responses were recorded and thematically coded. Results: The results show that teams do behave differently in different components, and the feedback from the teams indicates that this method of illustrating team behavior can be useful as a complement to traditional summary statistics of ownership. Conclusions: We find that our model-based approach produces useful visualizations of team introductions of code clones as they change different components. Practitioners stated that the visualizations gave them insights that were useful, and by comparing with an average team, inter-team comparisons can be avoided. Thus, this has the potential to be a useful feedback tool for teams in software development organizations that employ weak or collective ownership.

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

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

An initial Theory to Understand and Manage Requirements Engineering Debt in Practice

Context: Advances in technical debt research demonstrate the benefits of applying the financial debt metaphor to support decision-making in software development activities. Although decision-making during requirements engineering has significant consequences, the debt metaphor in requirements engineering is inadequately explored. Objective: We aim to conceptualize how the debt metaphor applies to requirements engineering by organizing concepts related to practitioners' understanding and managing of requirements engineering debt (RED). Method: We conducted two in-depth expert interviews to identify key requirements engineering debt concepts and construct a survey instrument. We surveyed 69 practitioners worldwide regarding their perception of the concepts and developed an initial analytical theory. Results: We propose a RED theory that aligns key concepts from technical debt research but emphasizes the specific nature of requirements engineering. In particular, the theory consists of 23 falsifiable propositions derived from the literature, the interviews, and survey results. Conclusions: The concepts of requirements engineering debt are perceived to be similar to their technical debt counterpart. Nevertheless, measuring and tracking requirements engineering debt are immature in practice. Our proposed theory serves as the first guide toward further research in this area.

cs.SE

Requirements Quality vs Process and Stakeholders' Well-being: A Case of a Nordic Bank

Requirements are key artefacts to describe the intended purpose of a software system. The quality of requirements is crucial for deciding what to do next, impacting the development process's effectiveness and efficiency. However, we know very little about the connection between practitioners' perceptions regarding requirements quality and its impact on the process or the feelings of the professionals involved in the development process. Objectives: This study investigates: i) How software development practitioners define requirements quality, ii) how the perceived quality of requirements impact process and stakeholders' well-being, and iii) what are the causes and potential solutions for poor-quality requirements. Method: This study was performed as a descriptive interview study at a sub-organization of a Nordic bank that develops its own web and mobile apps. The data collection comprises interviews with 20 practitioners, including requirements engineers, developers, testers, and newly employed developers, with five interviewees from each group. Results: The results show that different roles have different views on what makes a requirement good quality. Participants highlighted that, in general, they experience negative emotions, more work, and overhead communication when they work with requirements they perceive to be of poor quality. The practitioners also describe positive effects on their performance and positive feelings when they work with requirements that they perceive to be good.

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

"To Clean-Code or Not To Clean-Code" A Survey among Practitioners

Context: Writing Clean Code understandable by other collaborators has become crucial to enhancing collaboration and productivity. However, very little is known regarding whether developers agree with Clean Code Principles and how they apply them in practice.\\ Objectives: In this work, we investigated how developers perceive Clean Code principles, whether they believe that helps reading, understanding, reusing, and modifying Clean Code, and how they deal with Clean Code in practice. Methods: We conducted a Systematic Literature Review in which we considered 771 research papers to collect Clean Code principles and a survey among 39 practitioners, some of them with more than 20 years of development experience.\\ Results: So far, the results show a shared agreement with Clean Code principles and its potential benefits. They also show that developers tend to write messy code to be refactored later.

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

Assessing the Linguistic Quality of REST APIs for IoT Applications

Internet of Things (IoT) is a growing technology that relies on connected 'things' that gather data from peer devices and send data to servers via APIs (Application Programming Interfaces). The design quality of those APIs has a direct impact on their understandability and reusability. This study focuses on the linguistic design quality of REST APIs for IoT applications and assesses their linguistic quality by performing the detection of linguistic patterns and antipatterns in REST APIs for IoT applications. Linguistic antipatterns are considered poor practices in the naming, documentation, and choice of identifiers. In contrast, linguistic patterns represent best practices to APIs design. The linguistic patterns and their corresponding antipatterns are hence contrasting pairs. We propose the SARAv2 (Semantic Analysis of REST APIs version two) approach to perform syntactic and semantic analyses of REST APIs for IoT applications. Based on the SARAv2 approach, we develop the REST-Ling tool and empirically validate the detection results of nine linguistic antipatterns. We analyse 19 REST APIs for IoT applications. Our detection results show that the linguistic antipatterns are prevalent and the REST-Ling tool can detect linguistic patterns and antipatterns in REST APIs for IoT applications with an average accuracy of over 80%. Moreover, the tool performs the detection of linguistic antipatterns on average in the order of seconds, i.e., 8.396 seconds. We found that APIs generally follow good linguistic practices, although the prevalence of poor practices exists.

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

From Forced Working-From-Home to Working-From-Anywhere: Two Revolutions in Telework

The COVID-19 outbreak has admittedly caused a major disruption worldwide. The interruptions to production, transportation, and mobility have clearly had a significant impact on the well-functioning of the global supply and demand chain. But what happened to the companies developing digital services, such as software. Were they interrupted as much or at all? And how has the enforced Working-From-Home mode impacted their ability to continue to deliver software? We hear that some managers are concerned that their engineers are not working effectively from home, or even lack the motivation to work in general, that teams lose touch and that managers do not notice when things go wrong. In this article, we share our findings from monitoring the situation in an international software company with engineers located in Sweden, USA, and the UK. We analyzed different aspects of productivity, such as developer satisfaction and well-being, activity, communication and collaboration, efficiency and flow based on the archives of commit data, calendar invites, and Slack communication, as well as the internal reports of WFH experiences and 18 interviews. We find that company engineers continue committing code and carry out their daily duties without significant disruptions, while their routines have gradually adjusted to the new norm with new emerging practices and various changes to the old ones. In a way, our message is that there is no news, which is good news. Yet, the experiences gained with the WFH of such scale have already made significant changes in the software industry's future, work from anywhere being an example of major importance.

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