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. 

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. 

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.