arXiv subjects

Klara Borowa

Publications and source records attributed to Klara Borowa.

9 recordsLinked to original sources

arXiv2026

Hidden or Formal Architects: Understanding Who Makes Architectural Decisions in Practice

Empirical research on software architecture sometimes focuses on individuals holding the formal title of software architect. However, not all companies have individuals hired in such roles. Despite no formal architects, all systems have architectures, and there must be practitioners making the architectural decisions. This study aims to identify who, in practice, makes architectural decisions and in what environments the existence of a formal architect is perceived as necessary. This research employed a method consisting of a questionnaire with 54 participants from different companies and seven follow-up interviews. The findings indicate that architectural decisions are often made by individuals without a formal architect title. A formal architect is perceived as essential mainly in large companies and large teams. The results of this study show that many practitioners taking part in ADM may have been omitted by previous research, particularly if it focused on formal architects.

cs.SE↗

arXiv2026

How Software Engineering Research Overlooks Local Industry: A Smaller Economy Perspective

The software engineering researchers from countries with smaller economies, particularly non-English speaking ones, represent valuable minorities within the software engineering community. As researchers from Poland, we represent such a country. We analyzed the ICSE FOSE (Future of Software Engineering) community survey through reflexive thematic analysis to show our viewpoint on key software community issues. We believe that the main problem is the growing research-industry gap, which particularly impacts smaller communities and small local companies. Based on this analysis and our experiences, we present a set of recommendations for improvements that would enhance software engineering research and industrial collaborations in smaller economies.

cs.SE↗

arXiv2025

The Technical Debt Gamble: A Case Study on Technical Debt in a Large-Scale Industrial Microservice Architecture

Microservice architectures provide an intuitive promise of high maintainability and evolvability due to loose coupling. However, these quality attributes are notably vulnerable to technical debt (TD). Few studies address TD in microservice systems, particularly on a large scale. This research explores how TD manifests in a large-scale microservice-based industrial system. The research is based on a mixed-method case study of a project including over 100 microservices and serving over 15k locations. Results are collected via a quantitative method based static code analyzers combined with qualitative insights derived from a focus group discussion with the development team and a follow-up interview with the lead architect of the case study system. Results show that (1) simple static source code analysis can be an efficient and effective entry point for holistic TD discovery, (2) inadequate communication significantly contributes to TD, (3) misalignment between architectural and organizational structures can exacerbate TD accumulation, (4) microservices can rapidly cycle through TD accumulation and resolution, a phenomenon referred to as "microservice architecture technical debt gamble". Finally, we identify a set of fitting strategies for TD management in microservice architectures.

cs.SE↗

arXiv2025

Debiasing Architectural Decision-Making: An Experiment With Students and Practitioners

Cognitive biases are predictable, systematic errors in human reasoning. They influence decision-making in various areas, including architectural decision-making, where architects face many choices. For example, anchoring can cause architects to unconsciously prefer the first architectural solution that they came up with, without considering any solution alternatives. Prior research suggests that training individuals in debiasing techniques during a practical workshop can help reduce the impact of biases. The goal of this study was to design and evaluate a debiasing workshop with individuals at various stages of their professional careers. To test the workshop's effectiveness, we performed an experiment with 16 students and 20 practitioners, split into control and workshop group pairs. We recorded and analyzed their think-aloud discussions about improving the architectures of systems they collaborated on. The workshop improved the participants' argumentation when discussing architectural decisions and increased the use of debiasing techniques taught during the workshop. This led to the successful reduction of the researched biases' occurrences. In particular, anchoring and optimism bias occurrences decreased significantly. We also found that practitioners were more susceptible to cognitive biases than students, so the workshop had a more substantial impact on practitioners. We assume that the practitioners' attachment to their systems may be the cause of their susceptibility to biases. Finally, we identified factors that may reduce the effectiveness of the debiasing workshop. On that basis, we prepared a set of teaching suggestions for educators. Overall, we recommend using this workshop to educate both students and experienced practitioners about the typical harmful influences of cognitive bias on architectural decisions and how to avoid them.

cs.SE↗

arXiv2025

The TechDebt Game -- Enabling Discussions about Technical Debt

Context. Technical Debt (TD), defined as software constructs that are beneficial in the short term but may hinder future change, is a frequently used term in software development practice. Nevertheless, practitioners do not always fully understand its definition and, in particular, conceptual model. Previous research highlights that communication about TD is challenging, especially with non-technical stakeholders. Discussions on this topic often cause conflicts due to misunderstandings related to other stakeholders' perspectives. Goal. We designed a board game to emulate TD concepts to make them tangible to all stakeholders, including non-technical ones. The game aims to encourage discussions about TD in an emulated and safe environment, thereby avoiding real-life conflicts. Method. To evaluate the game's effectiveness, we surveyed 46 practitioners from diverse domains, positions, and experience levels who played the game in 13 sessions following extensive testing during its development. In addition to the players' general feedback, we examined situations where players recognized new insights about TD or connected game scenarios to real-life experiences. Results. Overall, the feedback on the game and its enjoyment factor were highly positive. While developers and software architects often connected game situations to their real-world experiences, non-technical stakeholders, such as scrum masters, product owners, and less experienced developers, encountered multiple new insights on TD. Numerous players have shifted their attitudes toward TD and have outlined a plan to modify their behavior regarding TD management. Conclusions. Although the game may not lead to long-term behavior change among stakeholders, participants' feedback provides evidence that it might serve as a valuable starting point for team discussions on technical debt management.

cs.SE↗

arXiv2023

What rationales drive architectural decisions? An empirical inquiry

Architectural decision-making is a crucial concern for researchers and practitioners alike. There is a rationale behind every architectural decision that motivates an architect to choose one architectural solution out of a set of options. This study aims to identify which categories of rationale most frequently impact architectural decisions and investigates why these are important to practitioners. Our research comprises two steps of empirical inquiry: a questionnaire (63 participants) and 13 interviews. As a result, we obtained a set of rationales that motivated architects' decisions in practice. Out of them, we extracted a list of software quality attributes that practitioners were the most concerned about. We found that, overall, architects prefer to choose solutions which are familiar to them or that guarantee fast software implementation. Mid-career architects (5 to 15 years of experience) are more open to new solutions than senior and junior practitioners. Additionally, we found that most practitioners are not concerned about the quality attributes of compatibility and portability due to modern software development practices, such as the prevalence of using specific standards and virtualisation/containerization.

cs.SE↗

arXiv2023

The Influence of Cognitive Biases on Architectural Technical Debt

Cognitive biases exert a significant influence on human thinking and decision-making. In order to identify how they influence the occurrence of architectural technical debt, a series of semi-structured interviews with software architects was performed. The results show which classes of architectural technical debt originate from cognitive biases, and reveal the antecedents of technical debt items (classes) through biases. This way, we analysed how and when cognitive biases lead to the creation of technical debt. We also identified a set of debiasing techniques that can be used in order to prevent the negative influence of cognitive biases. The observations of the role of organisational culture in the avoidance of inadvertent technical debt throw a new light on that issue.

cs.SE↗

arXiv2022

Debiasing architectural decision-making: a workshop-based training approach

Cognitive biases distort the process of rational decision-making, including architectural decision-making. So far, no method has been empirically proven to reduce the impact of cognitive biases on architectural decision-making. We conducted an experiment in which 44 master's degree graduate students took part. Divided into 12 teams, they created two designs - before and after a debiasing workshop. We recorded this process and analysed how the participants discussed their decisions. In most cases (10 out of 12 groups), the teams' reasoning improved after the workshop. Thus, we show that debiasing architectural decision-making is an attainable goal and provide a simple debiasing treatment that could easily be used when training software practitioners.

cs.SE↗

arXiv2021

Is knowledge the key? An experiment on debiasing architectural decision-making -- a pilot study

The impact of cognitive biases on architectural decision-making has been proven by previous research. In this work, we endeavour to create a debiasing treatment that would minimise the impact of cognitive biases on architectural decision-making. We conducted a pilot study on two groups of students, to investigate whether a simple debiasing presentation reporting on the influences of cognitive biases, can provide a debiasing effect. The preliminary results show that this kind of treatment is ineffective. Through analysing our results, we propose a set of modifications that could result in a better effect.

cs.SE↗