Large-scale software systems often experience architectural degradation, affecting maintainability, scalability, and quality. To investigate this, we conducted focus groups with senior practitioners across three large organizations. Our analysis revealed four core challenge areas: managing dependencies, ownership and organizational barriers, balancing agility with stability and cost, as well as documentation drift. These findings offer practical insights for mitigating architectural degradation in complex environments. 

Organizations often migrate monolithic architectures to microservices based on ad hoc data, expert opinions, or industry trends without assessing their specific context and needs. Such transitions tend to coincide with increased architectural complexity and technical debt (TD), making it crucial to understand how TD evolves over time in industrial settings to manage it effectively. This observational study explores the evolution of technical debt density (TDD) in a single software product consisting of both monolithic and microservice architectures at a Swedish fintech company, without aiming to establish causality between architectural styles and TDD trends. We further investigate TDD trends across various microservice size categories, team types, and the relationship between size and TDD. We analyzed SonarQube TD data collected from one monolith and 78 microservices from August 2022 to December 2024, and conducted semi-structured interviews with practitioners (a development manager, a product owner, and a lead developer) to validate and contextualize the quantitative findings. Our results show that, in this case, the monolithic system exhibits a decreasing TDD trend over time despite continued growth in size, while a gradual increase in TDD is observed across microservices. Furthermore, TDD trends appear inconsistent among small microservices, more consistently growing in medium-sized microservices, and comparatively stable in larger services. Differences in TDD trends are observed across services owned by platform teams and product teams. Overall, the findings from this specific case suggest that TDD evolves differently in monolith and microservices, highlighting the importance of continuous monitoring and context-aware interpretation of TDD trends in practice. 

Over the last decade, software organizations have increasingly adopted microservices to effectively deal with evolving software systems, frequent demands for new features, and changing technologies. However, microservices are not a silver bullet; their success depends on the specific context and needs of each organization. Therefore, tracking the evolution of architectural complexity indicators is crucial for effective architectural governance and decision-making. In this paper, we explore the relationship between architectural complexity indicators and their evolution, specifically declared dependencies, API endpoints, inter-service communications, size, and technical debt. We used the static source code analysis methods along with SonarQube to measure architectural complexity, collecting data on all indicators over the past two and a half years. Our findings indicate that architectural complexity consistently grows, even within microservices. Most importantly, these indicators co-evolve, making the overall architecture more complicated than expected. Additionally, all complexity indicators grow rapidly when services are small and still evolving. The insights gained from this study can assist organizations in effectively managing their microservices, highlighting when they might be most prone to architectural degradation. 

Background: Software Development organisations tend to organise the development of software-intensive products and services as a constellation of components meant to be developed and maintained by independent, autonomous teams. However, the maintenance and evolution of said products and services require team collaboration and coordination. This collaboration and coordination overhead piles on top of teams’ workload, often hindering teams’ throughput and lead time.

Objectives: This paper aims to discuss how the use of pull request data can help identify congested teams when the arrival of new tasks exceeds the team’s ability to close them. To do so, we have conducted an empirical study in a software development organisation developing a large-scale product, to try to characterise congested teams and the characteristics of the code reviews they are involved in.

Method: We have conducted a case study to start exploring how code review data can help us model team congestion, and understand whether the features of the code-review network, or the team type (platform vs product), can have a major impact on team congestion.

Results: The results show that teams seem to experience varying levels of congestion based on pull request activity, with some indicating potential congestion. However, increased PR accumulation did not consistently lead to longer lead times, as seen in some teams where high PR backlogs did not significantly impact delivery cadence.

Conclusions: Our findings suggest that while PR data can indicate potential congestion, its impact on lead time varies across teams. Both technical factors and unobserved contextual elements shape congestion. Deeper insights require combining repository metrics with qualitative inputs. 

The growing complexity, the ever-ending demands for new features, and the need to become faster to remain competitive force software development organizations to rethink their development and value delivery practices. While continuous delivery has become more popular, it still relies mainly on internal metrics, ad-hoc data, and expert opinions. As a result, software organizations stumble to find the balance between improving internal system quality and delivering external value. In fact, understanding and measuring customer value is on itself essential. In this PhD project, we aim for a better understanding of customer value and develop measurement instruments to be integrated with internal perspectives to drive proactive and continuous internal improvement while delivering relevant customer value. 

Background: Software companies must balance fast delivery and quality, a trade-off that often introduces technical debt and wastes developer's time. Technical debt tends to increase as software evolves, which is assumed to slow down development and maintenance activities. However, the potential relationship between technical debt and lead time lacks empirical evidence.

Objective: This paper reports an empirical study to explore the potential relationship between technical debt and lead time in resolving Jira tickets. We further aim to measure the extent to which technical debt can explain the variation in lead time.

Method: We conducted an industrial case study to explore this relationship in six components, each of which was analyzed individually. Technical debt was measured using SonarQube and normalized with the component's size. Lead times to resolve Jira tickets were collected from Jira and averaged monthly.

Results: The study found little to no correlation between technical debt and lead time to resolve Jira tickets in five components, with technical debt explaining a variation in lead time ranging from 0% to 41%. However, it is less than 30% in most of the components.

Conclusion: Technical debt alone does not fully explain the variation in lead time. There should be some other confounding variables (e.g., size and complexity of the changes, number of teams involved, priorities, component ownership) affecting lead time or a residual effect, i.e., interest, that might manifest later. Further investigation into those confounding variables is essential. 

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. © The Author(s) 2024.

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.

Methods:We performed an analysis of secondary literature and a field study at five companies to investigate and identify assets to fill the gap in research. The results were analysed qualitatively and summarised in a taxonomy.

Results:We present 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.

Seeking the advantages delivered by agile methods in small-scale software development, large organisations are also adopting agile methods. However, scaling results in a huge growth of socio-technical dependencies that can lead to waiting time, delays, and defects and hinder the teams' ability to recognize their own responsibilities. This research proposes an approach to enable teams' autonomy and clarifies teams' responsibility assignments by aligning socio-technical dependencies. By utilising compile-time, run-time, and task dependencies, our approach identifies the wasteful dependencies between the social structures (teams) and the corresponding technical structures (architecture) and also suggests improvements. The initial results suggest that the approach correctly identifies the wasteful dependencies that are hindering teams' responsibility assignments. The suggested solution proposals are also considered useful. Awareness of such wasteful dependencies is the first step toward being able to handle them successfully. © 2023 IEEE.

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.