Software organizations of all sizes are affected by the Technical debt phenomenon. Large organizations, however, are more prone to their non-technical aspects due to a large number of teams of different sizes, heterogeneity of expertise, and the need for continuous management and communication. This is even more emphasized in large agile software development contexts due to a focus on personal interactions and team collaboration, which consequently poses a challenge due to a significant increase in communication pathways. The goal of this study is to investigate non-technical aspects of technical debt in the context of large-scale agile software development. To achieve this objective, a case study involving four international companies was conducted. During the study, 24 experts were interviewed, and their responses were analyzed using a qualitative research approach. The analysis resulted in five non-technical aspects, which are: social dynamics, process, people, documentation, and requirements aspects, and their indicators, which are specific in a large-scale agile context. The study findings suggest that lack of communication, collaboration, and cooperation are the key contributors to identified debt aspects, technical debt accumulation through these non-technical aspects, and that many of the causes stem from a culture of not developing rules, protocols, or guidelines.

Background: Large language models (LLM) suffer from various forms of biases due to the biased datasets used to train the models. At the same time, human cognitive biases have an equal propensity to express themselves when using LLMs for software engineering tasks. Software testing is a critical phase of the software development life cycle. Confirmation bias is reported to have deteriorated software testing by designing more specification-consistent test cases compared to specificationinconsistent test cases. However, there is a lack of debiasing (mitigation) strategies in this regard. Aims: In this paper, first, we investigate whether the LLM model suffers from confirmation bias while performing software testing tasks. Second, we propose a vision of debasing confirmation bias in software testing via LLM. Method: We conducted an empirical study to detect confirmation bias by an LLM (ChatGPT4.0) in the design of functional test cases. Based on empirical findings, we used the analytical paradigm to design a multi-agent system. Results: We present a vision for debiasing confirmation bias in functional software testing by leveraging LLMs via a multi-agent approach. Conclusions: The proposed vision may improve the performance of LLMs in terms of reduced confirmation bias and serve as a debiasing technique for functional software testing.

Scaling agile approaches in large company context is prone to technical debt due to large number of teams of different size, level of expertise and their need for management and communication. The goal of this study is to investigate the phenomenon of non-technical debt related issues in the context of large-scale agile software development. To achieve this goal, eleven experts from two multinational companies were inter-viewed as part of the the case study. The analysis results revealed four non-technical aspects of technical debt that are present in large-scale agile context. These are people, social, documentation and process debt aspects. Furthermore, the findings suggest that lack of communication, collaboration and cooperation are the key contributors to identified debt aspects, and that many of the causes for debts are stemming from a culture of not developing rules, protocols, or guidelines. Implementing ground rules to improve quality seems to mitigate several of the identified debt types.

Context . Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims . To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method . We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results . Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion . This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study.

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. 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). 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. 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. 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.

Background: Software testers manifest confirmation bias (the cognitive tendency) when they design relatively more specification consistent test cases than specification inconsistent test cases. Time pressure may influence confirmation bias of testers per the research in the psychology discipline.Objective: We examine the manifestation of confirmation bias of software testers while designing functional test cases, and the effect of time pressure on confirmation bias in the same context.Method: We executed one internal and two external experimental replications concerning the original experimentation in Oulu. We analyse individual replications and meta-analyse our family of experiments (the original and replications) for joint results on the phenomena. Results: Our findings indicate a significant manifestation of confirmation bias by software testers during the designing of functional test cases. Time pressure significantly promoted confirmation bias among testers per the joint results of the family. The different experimental sites affected the results; however, we did not detect any effects of site-specific variables.Conclusion: Software testers should develop an outside-of-the-box thinking attitude to counter the manifestation of confirmation bias. Time pressure can be manoeuvred by centring manual suites on the designing and consequently the execution of inconsistent test cases, while automated testing focuses on consistent ones.

Desiderata is a general term for stakeholder needs, desires or preferences. Recent experiments demonstrate that presenting desiderata as templated requirements specifications leads to less creative solutions. However, these experiments do not establish how the presentation of desiderata affects design creativity. This study, therefore, aims to explore the cognitive mechanisms by which presenting desiderata as templated requirements specifications reduces creativity during software design. Forty-two software designers, organized into 21 pairs, participated in a dialog-based protocol study. Their interactions were transcribed and the transcripts were analyzed in two ways: (1) using inductive process coding and (2) using an a-priori coding scheme focusing on fixation and critical thinking. Process coding shows that participants exhibited seven categories of behavior: making design moves, uncritically accepting, rejecting, grouping, questioning, assuming and considering quality criteria. Closed coding shows that participants tend to accept given requirements and priority levels while rejecting newer, more innovative design ideas. Overall, the results suggest that designers fixate on desiderata presented as templated requirements specifications, hindering critical thinking. More precisely, requirements fixation mediates the negative relationship between specification formality and creativity.

Background. Software engineering is one of the engineering fields with the highest inflow of junior engineers. Tools that utilize source code analysis to provide feedback on internal software quality, i.e. Technical Debt (TD), are valuable to junior developers who can learn and improve their coding skills with minimal consultations with senior colleagues. Objective. We aim at understating which SonarQube TD items junior developers prioritize during the refactoring and how long they take to refactor them. Method. We designed a case study with replicated design and we conducted it with 185 junior developers in two countries, that developed 23 projects with different programming languages and architectures. Results. Junior developers focus homogeneously on different types of TD items. Moreover, they can refactor items in a fraction of the estimated time, never spending more than 50% of the time estimated by SonarQube. Conclusion. Junior Developers appreciate the usage of SonarQube and considered as a useful tool. Companies might ask junior developers to quickly clean their code.

Background: The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage. In recent years, various techniques and best practices in terms of TD management were proposed and although important on its own this knowledge must be complemented with a broader comprehension of what causes TD and what are the effects of TD. This paper presents a replication of the InsighTD survey-a globally distributed family of industrial surveys on causes and effects of TD-and thus amplifies the InsighTD reach and expands its knowledge base. Objective: The research presented in this paper gives insight on the state of practice and understanding of the TD concept alongside with data on causes and effects of TD in the Serbian IT industry. Method: A nation-wide survey, as a part of the InsighTD initiative, was conducted in Serbia in order to obtain feedback from software industry practitioners. Results: In total 93 practitioners from the Serbian IT industry filled out the survey. The results indicate that the concept of TD is broadly distributed, but at the same time it is not widely accepted for use (only 35% of participants had some sort of practical experiences with projects that were TD aware). The top cited causes were: deadlines, ineffective project management, lack of experience, test not performed and misconduct. On the other side the most common effects of TD were: low maintainability, increased effort, rework and low external quality. Conclusion: The research presented in this paper confirms the original study findings that deadlines are the top cited cause of TD. It also identifies new causes of TD in the context of InsighTD, with misconduct being one of the most cited ones. Regarding the effects of TD this research differs in most of the top 10 identified effects from the original study but confirms the occurrence of some effects most cited.

Background: There is a growing body of knowledge on Technical Debt (TD) in recent years. This knowledge provides various explanations of the term and suggests different remedies for it. However, the knowledge is yet to be validated in software development processes. Aims: The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in Serbian IT industry. Second, to contribute towards precise conceptualization of the TD concept. Method: We conducted a national-wide survey to collect feedback from industry practitioners. The survey is a part of InsighTD-an international initiative to investigate causes and effects of TD. Results: In total, 93 responses were collected, mostly from developers. Results indicate that the concept of TD is not widely accepted for use by the industry, only 35% of practitioners have practical experiences with projects that explicitly considered or managed TD. The most common types of TD are: code, test and design debt that together account for 61% of all reported cases. The archetypal TD case is caused by a tight schedule and resulted with non-optimal solutions that are difficult to evolve and in constant need of rework. Conclusions: Implications are at one hand for academics, who should consider TD as a topic for their curriculums since the results revealed that novice developers are unfamiliar with the concept. At the other hand, industry practitioners have a well aligned understanding of the TD concept, which is consistent with TD literature. However, we perceive that the wider use of the existing tools and techniques for managing TD can significantly help practitioners to deal with the top three occurring TD types.

Business value analysis (BVA) quantifies the factors that provide value and cost to an organization. It aims at capturing value, controlling risks, and capitalizing on opportunities. GQM+Strategies is an approach designed to aid in the definition and alignment of business goals, strategies, and an integrated measurement program at all levels in the organization. In this paper we describe how to perform business value analysis (BVA) using the GQM+Strategies approach. The integration of these two approaches provides a coupling of cost-benefit and risk analysis (value goals) with operationally measurable business goals and supports the evaluation of business goal success and the effectiveness of the chosen strategies. An application of the combined approach is provided to illustrate the feasibility of the proposed method. It deals with the business goal of modernizing the product for the evolving market.