Andrej Katin

dblp:277/0405 · DBLP profile ↗
← Back
3ranked-venue papers
0as first author
2since 2021 · last 2026
0000-0001-9755-3733ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 3 · 2 since 2021Applied, interdisciplinary, general and emerging computing · 1 · 1 since 2021
YearPublicationVenuePosition
2026 Technical debt is not just technical: An industrial case study in large agile software development
abstract
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.
Muhammad Ovais Ahmad, Vladimir Mandic, Nebojsa Tausan, Andrej Katin, Pavithra Herath
J. Syst. Softw.4
2024 Non- Technical Aspects of Technical Debt in the Context of Large-Scale Agile Development: A Qualitative Study
abstract
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.
Muhammad Ovais Ahmad, Tomas Gustavsson, Andrej Katin, Nebojsa Tausan, Vladimir Mandic
SEAA3
2020 How long do Junior Developers take to Remove Technical Debt Items?
abstract
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.
Valentina Lenarduzzi, Vladimir Mandic, Andrej Katin, Davide Taibi 0001
ESEM3